idnits 2.17.1 draft-ietf-midcom-framework-02.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. == There is 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There is 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 295: '... Middlebox communication protocol MUST...' RFC 2119 keyword, line 714: '... middlebox MUST not process signalin...' RFC 2119 keyword, line 767: '...stration process MUST take place. Regi...' RFC 2119 keyword, line 1621: '...ure does not and MUST not, in anyway, ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 166 has weird spacing: '...ress to provi...' == Line 238 has weird spacing: '... one of the e...' == Line 1006 has weird spacing: '...llowing timel...' == Line 1539 has weird spacing: '...nd will follo...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Host authenticity and individual message security are two distinct types of security considerations. Host authentication refers to credentials required of a MIDCOM agent to authenticate itself to the middlebox and vice versa. When authentication fails, the middlebox MUST not process signaling requests received from the agent that failed authentication. Two-way authentication should be supported. In some cases, the 2-way authentication may be tightly linked to the establishment of keys to protect subsequent traffic. Two-way authentication is often required to prevent various active attacks on the MIDCOM protocol and secure establishment of keying material. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: By adopting MIDCOM architecture, middleboxes will be able to support newer applications they have not been able to support thus far. MIDCOM architecture does not and MUST not, in anyway, change the fundamental characteristic of the services supported on the middlebox. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 739, but not defined == Missing Reference: 'IPSEC-ESP' is mentioned on line 741, but not defined == Unused Reference: 'IETF-STD' is defined on line 1785, but no explicit reference was found in the text == Unused Reference: 'RTSP' is defined on line 1802, but no explicit reference was found in the text == Unused Reference: 'FTP' is defined on line 1805, but no explicit reference was found in the text == Unused Reference: 'NAT-COMP' is defined on line 1816, but no explicit reference was found in the text == Unused Reference: 'MIDCOM-REQ' is defined on line 1828, but no explicit reference was found in the text == Unused Reference: 'APPL-ID' is defined on line 1832, but no explicit reference was found in the text == Unused Reference: 'RFC 1918' is defined on line 1836, but no explicit reference was found in the text == Unused Reference: 'RFC 1700' is defined on line 1840, but no explicit reference was found in the text == Unused Reference: 'IPsec-AH' is defined on line 1843, but no explicit reference was found in the text == Unused Reference: 'IPsec-ESP' is defined on line 1846, but no explicit reference was found in the text == Unused Reference: 'TLS' is defined on line 1849, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1602 (ref. 'IETF-STD') (Obsoleted by RFC 2026) ** 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') ** Downref: Normative reference to an Informational RFC: RFC 3027 (ref. 'NAT-COMP') ** Obsolete normative reference: RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) -- Possible downref: Non-RFC (?) normative reference: ref. 'NAT-FRAMEWORK' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIDCOM-REQ' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** 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. 'SEC-GUIDE' Summary: 20 errors (**), 0 flaws (~~), 22 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Srisuresh 3 INTERNET-DRAFT Jasmine Networks 4 Expires as of December 13, 2001 J. Kuthan 5 GMD Fokus 6 J. Rosenberg 7 Dynamicsoft 8 A. Molitor 9 Aravox Technologies 10 A. Rayhan 11 Consultant 12 June, 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 enable complex applications 54 through the middleboxes seamlessly using a trusted third party. 56 1. Introduction 58 Intermediate devices requiring application intelligence are the 59 subject of this document. These devices are referred as 60 middleboxes throughout the document. Many of these devices enforce 61 application specific policy based functions such as packet 62 filtering, differentiated Quality of Service, tunneling, Intrusion 63 detection, security and so forth. Network Address Translator 64 service, on the other hand, provides routing transparency across 65 address realms (within IPv4 routing network or across V4 and V6 66 routing realms). Application Level gateways (ALGs) are used in 67 conjunction with NAT to provide end-to-end transparency for many of 68 the applications. There may be other types of services requiring 69 embedding application intelligence in middleboxes for their 70 operation. The discussion scope of this document is however limited 71 to middleboxes implementing Firewall and NAT services only. 72 Nonetheless, the middlebox framework is designed to be extensible 73 to support the deployment of new services. 75 Tight coupling of application intelligence with middleboxes makes 76 maintenance of middleboxes hard with the advent of new applications. 77 Built-in application awareness typically requires updates of 78 operating systems with new applications or newer versions of 79 existing applications. Operators requiring support for newer 80 applications will not be able to use third party software/hardware 81 specific to the application and are at the mercy of their 82 middlebox vendor to make the necessary upgrade. Further, embedding 83 intelligence for a large number of application protocols within 84 the same middlebox increases complexity of the middlebox and is 85 likely to be error prone and degrade in performance. 87 This document describes a framework in which application 88 intelligence can be moved from middleboxes into external MIDCOM 89 agents. The premise of the framework is to devise a MIDCOM 90 protocol that is application independent, so the middleboxes 91 can stay focused on services such firewall and NAT. MIDCOM 92 agents with application intelligence can, in turn, assist the 93 middleboxes through the MIDCOM protocol in permitting applications 94 such as FTP, SIP and H.323. The communication between a MIDCOM 95 agent and a middlebox will be transparent to the end-hosts that 96 take part in the application, unless one of the end-hosts assumes 97 the role of a MIDCOM agent. Discovery of middleboxes in the path 98 of an application instance and communication amongst middleboxes 99 is outside the scope of this document. 101 This document describes the framework in which middlebox 102 communication takes place and the various elements that constitute 103 the framework. Section 2 describes the terms used in the document. 104 Section 3 defines the architectural framework of a middlebox for 105 communication with MIDCOM agents. The remaining sections cover the 106 components of the framework, illustration using sample flows and 107 operational considerations with the MIDCOM architecture. Section 4 108 describes the nature of MIDCOM protocol. Section 5 identifies 109 entities that could potentially host the MIDCOM agent function. 110 Section 6 considers the role of Policy server and its function 111 with regard to communicating MIDCOM agent authorization policies. 112 Sections 7 and 8 are illustration of MIDCOM framework with sample 113 flows using In-Path and out-of-path agents respectively. Section 9 114 addresses operational considerations in deploying a protocol 115 adhering to the framework described here. Section 10 is an 116 applicability statement, scoping the location of middleboxes. 117 Section 12 outlines security considerations for the middlebox 118 in view of the MIDCOM framework. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 124 this document are to be interpreted as described in RFC 2119. 125 Below are the definitions for the terms used throughout the 126 document. 128 2.1. MiddleBox function/service 130 A middlebox function or a middlebox service is an operation or 131 method performed on a network intermediary that requires application 132 specific intelligence for its operation. Policy based packet 133 filtering (a.k.a. firewall), Network address translation (NAT), 134 Intrusion detection, Load balancing, Policy based tunneling and 135 IPsec security are all examples of a middlebox function (or 136 service). 138 2.2. MiddleBox 140 Middlebox is a network intermediate device that implements one or 141 more of the middlebox services. A NAT middlebox is a middlebox 142 implementing NAT service. A firewall middlebox is a middlebox 143 implementing firewall service. 145 2.3. Firewall 147 Firewall is a policy based packet filtering Middlebox function, 148 typically used for restricting access to/from specific devices and 149 applications. The policies are often termed Access Control 150 Lists (ACLs). 152 2.4. NAT 154 Network Address Translation is a method by which IP addresses are 155 mapped from one address realm to another, providing transparent 156 routing to end-hosts. This is achieved by modifying end node 157 addresses en-route and maintaining state for these updates so 158 that datagrams pertaining to a session are forwarded to the right 159 end-host in either realm. Refer [NAT-TERM] for the definition of 160 various NAT types and the associated terms in use. 162 The term NAT in this document is very similar to the IPv4 NAT 163 described in [NAT-TERM], but is extended beyond IPv4 networks 164 to include the IPv4-v6 NAT-PT described in [NAT-PT]. While the 165 IPv4 NAT [NAT-TERM] translates one IPv4 address into another IPv4 166 address to provide routing between private V4 and external V4 167 address realms, IPv4-v6 NAT-PT [NAT-PT] translates an IPv4 address 168 into an IPv6 address and vice versa to provide routing between a 169 V6 address realm and an external V4 address realm. 171 Unless specified otherwise, NAT in this document is a middlebox 172 function referring to both IPv4 NAT as well as IPv4-v6 NAT-PT. 174 2.5. Proxy 176 A proxy is an intermediate relay agent between clients and servers 177 of an application, relaying application messages between the two. 178 Proxies use special protocol mechanisms to communicate with proxy 179 clients and relay client data to servers and vice versa. A Proxy 180 terminates sessions with both the client and the server, acting as 181 server to the end-host client and as client to the end-host server. 183 Applications such as FTP, SIP and RTSP use a control connection to 184 establish data sessions. These control and data sessions can take 185 divergent paths. While a proxy can intercept both the control and 186 data connections, it might intercept only the control connection. 187 This is often the case with real-time streaming applications such 188 as SIP and RTSP. 190 2.6. ALG 192 Application Level Gateways (ALGs) are agents that possess the 193 application specific intelligence and knowledge of an associated 194 middlebox function. An ALG examines application traffic in transit 195 and assists middlebox in carrying out its function. 197 An ALG may be co-resident with a middlebox or reside externally, 198 communicating through a middlebox communication protocol. It 199 interacts with a middlebox to set up state, access control 200 filters, use middlebox state information, modify application 201 specific payload or perform whatever else is necessary to enable 202 the application to run through the middlebox. 204 ALGs are different from proxies. ALGs are transparent to 205 end-hosts, unlike the proxies which are relay agents terminating 206 sessions with both end-hosts. ALGs do not terminate session with 207 either end-host. Instead, ALGs examine and optionally modify 208 application payload content to facilitate the flow of application 209 traffic through a middlebox. ALGs are middlebox centric, in that 210 they assist the middleboxes in carrying out their function. 211 Whereas, the proxies act as focal point for application servers, 212 relaying traffic between application clients and servers. 214 ALGs are similar to Proxies, in that, both ALGs and proxies 215 facilitate Application specific communication between clients 216 and servers. 218 2.7. End-Hosts 220 End-hosts are entities that are party to a networked application 221 instance. End-hosts referred in this document are specifically 222 those terminating Real-time streaming Voice-over-IP 223 applications such as SIP and H.323 and peer-to-peer applications 224 such as Napster and NetMeeting. 226 2.8. MIDCOM Agents 228 MIDCOM agents are entities performing ALG function, logically 229 external to a middlebox. MIDCOM agents possess a combination of 230 application awareness and knowledge of the middlebox function. 231 A MIDCOM agent may communicate with one or more middleboxes. 233 MIDCOM agents may be located either In-Path or Out-of-path of 234 an application instance. In-Path MIDCOM agents are those in 235 which the MIDCOM agent function is co-resident on devices that 236 are naturally within the message path of the application they 237 are associated with. This may be an application proxy, gateway, 238 or in the extreme case, one of the end-hosts, that is party to 239 the application. Out-of-Path (OOP) MIDCOM agents are those that 240 are not necessarily resident (or co-resident) on entities that 241 are natively in the path of application flows. 243 2.9. Policy Server 245 Policy Server is a management entity that acts in advisory 246 capacity and interfaces with a middlebox to communicate policies 247 concerning authorization of MIDCOM agents gaining access to 248 middlebox resources. A MIDCOM agent may be pre-configured on a 249 middlebox. In the case where a MIDCOM agent is not pre-configured, 250 the middlebox will consult Policy Server out-of-band and obtain 251 the agent profile to validate connection setup and authorization 252 of the agent to gain access to middlebox resources. Once an agent 253 is connected to the middlebox, the policy server may at anytime 254 notify the middlebox to terminate authorization for the agent. 256 The protocol facilitating the communication between a middlebox 257 and Policy Server need not be part of MIDCOM protocol. Section 6 258 in the document addresses the Policy server interface and protocol 259 framework independent of the MIDCOM framework. 261 Application specific policy data and policy interface between an 262 agent or application endpoint and a policy server is out of scope 263 for this document. The Policy server issues addressed in the 264 document are focussed at an aggregate domain level as befitting 265 the middlebox. For example, a SIP midcom agent may choose to 266 query a policy server for the administrative (or corporate) 267 domain to find whether a certain user is allowed to make an 268 outgoing call. This type of application specific policy data, as 269 befitting an end user is out of bounds for the Policy server 270 considered in this document. It is within bounds however for the 271 middlebox policy server to specify the specific end-user 272 applications (or tuples) for which an agent is permitted to be 273 an ALG. 275 2.10. Middlebox Communication (MIDCOM) protocol 277 The protocol between a MIDCOM agent and a middlebox that allows 278 the MIDCOM agent to gain access to middlebox resources and 279 allows the middlebox to delegate application specific processing 280 to MIDCOM agent. The MIDCOM protocol allows the middlebox to 281 perform its operation with the aid of MIDCOM agents, without 282 resorting to embedding application intelligence. The principal 283 motivation behind architecting this protocol is to enable complex 284 applications through middleboxes seamlessly using a trusted third 285 party, i.e., a MIDCOM agent. 287 This is a protocol yet to be devised. 289 3.0 Architectural framework for Middleboxes 291 A middlebox may implement one or more of the middlebox functions 292 selectively on multiple interfaces of the device. There can be a 293 variety of MIDCOM agents interfacing with the middlebox to 294 communicate with one or more of the middlebox functions on an 295 interface. As such, the Middlebox communication protocol MUST 296 allow for selective communication between a specific MIDCOM agent 297 and one or more middlebox functions on the interface. The following 298 diagram identifies a possible layering of the service supported 299 by a middlebox and a list of MIDCOM agents that might interact 300 with it. 302 +---------------+ +--------------+ +-------------+ 303 | MIDCOM agent | | MIDCOM agent | | Stand-alone | 304 | co-resident on| | co-resident | | MIDCOM agent| 305 | Proxy Server | | on Appl. GW | | (OOP Agent) | 306 +---------------+ +--------------+ +-------------+ 307 ^ ^ ^ 308 | | | +--------+ 309 | | MIDCOM | | Policy | 310 | | Protocol | +-| Server | 311 | | | / +--------+ 312 +-------------+ | | | / 313 | MIDCOM agent| | | | / 314 | co-resident | | | | / 315 | on End-hosts|<-+ | | | / 316 +-------------+ | | | | | 317 v v v v v 318 +-------------------------------------------+ 319 | Middlebox Communication |Policy | 320 | Protocol (MIDCOM) Interface |Interface | 321 +----------+--------+-----------+-----------+ 322 Middlebox | | | | | 323 Functions | Firewall | NAT | DiffServ- | Intrusion | 324 | | | QOS | Detection | 325 +----------+--------+-----------+-----------+ 326 Middlebox | Firewall ACLs, Session-descriptors, | 327 Managed | NAT-BINDs, NAT Address-Maps and other | 328 Resources | Middlebox function specific attributes | 329 +-------------------------------------------+ 331 Figure 1: MIDCOM agents interfacing with a middlebox 333 Resources such as a Session-Descriptor may be shared across 334 middlebox functions. A Session-Descriptor may uniquely identify 335 a session denoted by the tuple of (SessionDirection, 336 SourceAddress, DestinationAddress, Protocol, SourcePort, 337 DestinationPort). An aggregated Session-Descriptor, on the other 338 hand, may have one of the tuple elements denoted by a regular 339 expression (ex: Any source port). The attributes associated 340 with a Session-Descriptor may be specific to the individual 341 middlebox function. As Session-Descriptors may be shared across 342 middlebox functions, a Session-Descriptor may be created by a 343 function, and terminated by a different function. For example, a 344 session-descriptor may be created by the firewall function, but 345 terminated by the NAT function, when a session timer expires. 347 A middlebox may also have function specific resources such as 348 Address maps and Address binds to enforce NAT function and 349 application based policies to enforce firewall function. 350 Application specific MIDCOM agents (co-resident on the middlebox 351 or external to the middlebox) would examine the IP datagrams and 352 help identify the application the datagram belongs to and assist 353 the middlebox in performing functions unique to the application 354 and the middlebox service. For example, a MIDCOM agent assisting 355 a NAT middlebox might perform payload translations; whereas a 356 MIDCOM agent assisting a firewall middlebox might request the 357 firewall to permit access to application specific dynamically 358 generated session traffic. 360 4. MIDCOM Protocol 362 The MIDCOM protocol between a MIDCOM agent and a middlebox allows 363 the MIDCOM agent to gain access to middlebox resources and 364 allows the middlebox to delegate application specific processing 365 to MIDCOM agent. The protocol will allow MIDCOM agents to signal 366 the middleboxes to let complex applications using dynamic port 367 based sessions through them (i.e., middleboxes) seamlessly. 369 It is important to note that an agent and a middlebox can be on 370 the same physical device. In such a case, it is not desirable 371 for them to communicate using MIDCOM protocol. They may communicate 372 using a MIDCOM protocol message formats, but using a non-IP based 373 transport such as IPC messaging (or) they may communicate using a 374 well-defined API/DLL (or) the application intelligence is fully 375 embedded into the middlebox service (as it is done today in many 376 stateful inspection firewall devices and NAT devices). 378 The MIDCOM protocol will consist of a connection setup phase, 379 run-time connection phase and a connection termination phase. 381 Connection setup must be preceded by registration of the 382 MIDCOM agent with either the middlebox or the Policy Server. 383 The MIDCOM agent access and authorization profile may either 384 be pre-configured on the middlebox (or) listed on a Policy 385 Server the middlebox is configured to consult. MIDCOM is a 386 peer-to-peer protocol. As such, either the agent or the 387 middlebox may choose to initiate the connection. 389 A MIDCOM session may be terminated by either of the parties. 390 Alternately, a MIDCOM session termination may be triggered by 391 one of (a) agent going out of service and not being available 392 for further MIDCOM operations, or (b) a policy server notifying 393 the middlebox that a particular MIDCOM agent is no longer 394 authorized for a particular set of sessions any longer. 396 The MIDCOM protocol data exchanged during run-time is governed 397 principally by the middlebox services the protocol supports. 398 Firewall and NAT middlebox services are considered in this 399 document. Nonetheless, the MIDCOM framework is designed to 400 be extensible to support deployment of other services as well. 402 Few of the middlebox services are stateless. There are many that 403 are stateful and maintain per-connection state in the system. 404 Firewall service may be implemented as a stateless list of ACLs. 405 Many firewall implementations, however, are stateful. NAT 406 service, on the other hand, is inherently stateful. As such, 407 support of the MIDCOM protocol will require a middlebox to be 408 stateful. Here is why. 410 Let us consider the case of a middlebox implementing firewall 411 service. With the advent of MIDCOM protocol, the middlebox is 412 required to allocate dynamic resources, such as pin-holes, 413 upon request from agents. Explicit release of dynamically 414 allocated resources happens when the application session is 415 ended or when a Midcom agent requests the middlebox to release 416 the resource. However, the middlebox must be able to recover the 417 dynamically allocated resources at some point in time even if 418 the agent that was responsible for the dynamic allocation is not 419 alive. Typically, this is done by tracking the state of each 420 dynamically allocated pin-hole with some type of a timer. 421 This goes to show that even the firewall function will need to 422 maintain per-connection state, as a requirement to support the 423 MIDCOM protocol. 425 5.0. MIDCOM Agents 427 MIDCOM agents are logical entities which may reside physically 428 on nodes external to a middlebox, possessing a combination of 429 application awareness and knowledge of middlebox function. A 430 MIDCOM agent may communicate with one or more middleboxes. The 431 issues of middleboxes discovering agents or vice versa are 432 outside the scope of this document. The focus of the document 433 is the framework in which a MIDCOM agent communicates with a 434 middlebox using MIDCOM protocol, which is yet to be devised. 436 We will examine two types of MIDCOM agents in the following 437 sub-sections. 439 5.1. In-path MIDCOM agents 441 In-Path MIDCOM agents are entities that have a native role in the 442 path of the application traversal (with prior knowledge to one of 443 the application end-hosts), independent of their MIDCOM function. 444 Bundled session applications such as H.323, SIP and RTSP which 445 have separate control and data sessions may have their 446 sessions take divergent paths. In those scenarios, In-Path MIDCOM 447 agents are those that find themselves in the control path. 448 In majority of cases, a middlebox will likely require the 449 assistance of a single agent for an application in the control 450 path alone. However, it is possible that a middlebox function 451 might require the intervention of more than a single MIDCOM 452 agent for the same application, one for each sub-session of the 453 application. 455 Application Proxies and gateways are a good choice for In-Path 456 MIDCOM agents, as these entities, by definition, are in the path 457 of an application between a client and server. In addition to 458 hosting the MIDCOM agent function, these natively in-path 459 application specific entities may also enforce 460 application-specific choices locally, such as dropping messages 461 infected with known viruses, or lacking user authentication. 462 These entities can be interjecting both the control and data 463 connections. For example, FTP control and Data sessions are 464 interjected by an FTP proxy server. However, proxies may also be 465 interjecting just the control connection and not the data 466 connections, as is the case with real-time streaming applications 467 such as SIP and RTSP. Note, applications may not always traverse 468 a proxy and some applications may not have a proxy server 469 available. 471 SIP proxies and H.323 gatekeepers may be used to host MIDCOM 472 agent function to control middleboxes implementing firewall and 473 NAT functions. The advantage of using in-path entities as opposed 474 to creating an entirely new agent is that the in-path entities 475 already possess application intelligence. You will need to merely 476 enable the use of MIDCOM protocol to be an effective MIDCOM 477 agent. Figure 2 below illustrates a scenario where the in-path 478 MIDCOM agents interface with the middlebox. Let us say, the 479 policy Server has pre-configured the in-path proxies as trusted 480 MIDCOM agents on the middlebox and the packet filter 481 implements 'default-deny' packet filtering policy. Proxies use 482 their application-awareness knowledge to control the firewall 483 function and selectively permit a certain number of voice stream 484 sessions dynamically using MIDCOM protocol. 486 In the illustration below, the proxies and the policy server are 487 shown inside a private domain. The intent however is not to imply 488 that they be inside the private boundary alone. The proxies may 489 also reside external to the domain. The only requirement is that 490 there be a trust relationship with the middlebox. 492 +-----------+ 493 | Middlebox | 494 | Policy | 495 | Server |~~~~~~~~~~~~~| 496 +-----------+ \ 497 \ 498 +--------+ \ 499 | SIP |___ \ 500 ________| Proxy | \ Middlebox \ 501 / +--------+.. | +--------------------+ 502 | : | MIDCOM | | | 503 | RSTP +---------+ :..|........| MIDCOM | POLICY | 504 SIP | ____| RSTP |.....|........| PROTOCOL | INTER- | 505 | / | Proxy |___ | | INTERFACE | FACE | 506 | | +---------+ \ \ |--------------------| 507 | | \ \-----| | 508 | | \-------| | 509 | | ---| FIREWALL |-->-- 510 +-----------+ /---| |--<-- 511 +-----------+| Data streams // +--------------------+ 512 +-----------+||---------->----// | 513 |end-hosts ||-----------<----- . 514 +-----------+ (RTP, RSTP data, etc.) | 515 . Outside the 516 Within a private domain | private domain 518 Legend: ---- Application data path datagrams 519 ____ Application control path datagrams 520 .... Middlebox Communication Protocol (MIDCOM) 521 ~~~~ MIDCOM Policy Server Interface 522 | 523 . private domain Boundary 524 | 526 Figure 2: In-Path MIDCOM Agents for Middlebox Communication 528 5.1.1. End-hosts as In-Path MIDCOM agents 530 End-hosts are another variation of In-Path MIDCOM agents. Unlike 531 Proxies, End-hosts are direct party to the application and 532 possess all the end-to-end application intelligence there is to 533 it. End-hosts terminate both the control and data paths of an 534 application. Unlike other entities hosting MIDCOM agents, end-host 535 is able to process secure datagrams. However, the problem 536 would be one of manageability - upgrading all the end-hosts 537 running a specific application. 539 5.2. Out-of-Path MIDCOM agents 541 Out-of-Path MIDCOM agents (a.k.a. OOP agents) are entities that 542 are not natively in the transport path of an application. 543 OOP Agents have a role in the application traversal, only by 544 virtue of their MIDCOM function. No native role otherwise. It 545 would be safe to assume that OOP agents are not in the path 546 of application traversal. Out-of-Path agents have a few 547 benefits. Out-of-Path agents can be implemented in a system, 548 independent of any pre-existing application-aware entity. Unlike 549 In-path agents, there are no topological restrictions to where 550 the agents can be located. Further, multiple application 551 specific agents can be grouped together on the same node. 553 There is however a significant difference between in-path MIDCOM 554 agents and Out-of-path MIDCOM agents in the way the middlebox 555 directs application specific traffic for processing by the 556 agents. During connection establishment, an agent would identify 557 itself as either In-Path or Out-Of-Path(OOP) to the middlebox. 558 When an agent is naturally in the transport path of the 559 application (as is the case with an In-Path MIDCOM agent), there 560 is no additional effort required of the middlebox in redirecting 561 the application traffic. The middlebox cannot assume the same 562 with an OOP agent and hence will need to explicitly redirect 563 datagrams to the agent. The out-of-path MIDCOM agent should in 564 turn be capable of returning the processed traffic to the 565 middlebox point of origin or forwarding to the destination. 567 In essence, a middlebox provides to an Out-of-Path MIDCOM agent 568 the ability to transparently "snoop" and modify the control 569 traffic. It is reasonable to further classify Out-of-Path agents 570 into those which modify control traffic, and those which do not. 571 For example, if an Out-of-Path agent is used simply to manage 572 firewall policy for SIP-based telephony, it is enough to simply 573 forward SIP messages to the agent for examination. On the 574 other hand, if the agent must also manage NAT bindings, the 575 agent needs to modify the SIP messages, and re-inject them into 576 the control path. 578 In order to support Out-of-Path agents, the middlebox will require 579 an additional "Datagram Diverter" functional component. This 580 function is strictly to support the Out-of-path MIDCOM agents and 581 is independent of any middlebox service or application. Such a 582 Datagram diverter function is also independent of the MIDCOM 583 protocol, per se. The diverter function on the middlebox would be 584 required to do the following. 586 1. When a datagram is received by the middlebox, the middlebox 587 will subject the datagram to the standard middlebox services as 588 appropriate. However, if the datagram is designated for diversion 589 (i.e., the application specific MIDCOM agent is registered as 590 OOP), the middlebox will redirect the datagram to the diversion 591 target. 593 The datagram will have been directed to an application specific 594 payload processing entity. As such, this may be accomplished using 595 some type of tunneling mechanism (or) Remote procedure Call (RPC) 596 (or) some other proprietary mechanism. 598 2. The recipient of the diverted datagram (i.e., the OOP agent) will 599 snoop and optionally modify the payload (as appropriate to the 600 middlebox service) and does one of the following. Of these, the 601 safe thing to assume would be the first option. 603 (a) Send the processed datagram right back to the middlebox 604 using the same diversion approach the middlebox used. 605 (or) 606 (b) Forward the datagram to the appropriate destination 607 (i.e., one of the end-hosts that is party to the 608 application). This assumes that the OOP agent has 609 routing/forwarding capability. 611 3. When the middlebox receives a diverted (i.e., co-processed) 612 datagram from the OOP agent, the middlebox will simply forward 613 the processed datagram to the appropriate destination (i.e., one 614 of the end-hosts that is party to the application). Note, the 615 middlebox will not subject the datagram to any of the middlebox 616 services (i.e., NAT or firewall) this time around. 618 Note, Step 2a followed by step 3 would be same as going with 619 step 2b by itself. Below is an illustration of a scenario where 620 Out-of-path MIDCOM agents interface with the middlebox. The 621 middlebox is assumed to implement firewall service on it. Let us 622 say, the Out-of-path agents are pre-configured as trusted MIDCOM 623 agents on the middlebox and the packet filter implements 624 'default-deny' packet filtering policy. The OOP agents register 625 themselves as the diversion traffic targets for the applications 626 they support. They snoop the payload of the diverted traffic and 627 use application-awareness knowledge to control the firewall 628 function and selectively permit a certain number of FTP or voice 629 stream sessions dynamically using the MIDCOM protocol. 631 +---------+ Snooped ftp-control traffic 632 | FTP OOP |============>=============================\ 633 | Agent |++++++++++++<++++++++++++++++++++++++++++ || 634 | | Diverted ftp-control traffic + || 635 +---------+ + || 636 : + || 637 : +----------+ Snooped SIP traffic + || 638 : | SIP OOP |=========>===============\ + || 639 : | Agent |+++++++++<++++++++++++++ || + || 640 : | | Diverted SIP traffic + || + || 641 : +----------+ + || + || 642 : : + || + || 643 : : +-----------+ + || + || 644 : : | Middlebox | + || + || 645 : : | Policy |~~~~~| + || + || 646 : : | Server | \ + || + || 647 : : +-----------+ \ + || + || 648 : : \ + || + || 649 : :.............. \ + || + || 650 : MIDCOM : \ + || + || 651 :................. : \ + || + || 652 : : \ + || + || 653 +-----------+-----------+-----------+ 654 | | | | 655 | MIDCOM | POLICY | DATAGRAM | 656 | PROTOCOL | INTERFACE | DIVERSION | 657 | INTERFACE | | INTERFACE | 658 +------------+ +-----------+-----------+-----------+ 659 +------------+|------>----| FIREWALL |->- 660 +------------+||------<----| |-<- 661 |end-hosts || Ctrl +Data +-----------------------------------+ 662 +------------+ (SIP, RTP, FTP-CTRL, | 663 FTP-Data, etc.) . 664 | 665 Within a private domain . Outside the 666 | private domain 668 Legend: ---- Application data & control path datagrams 669 .... Middlebox Communication Protocol (MIDCOM) 670 ~~~~ MIDCOM Policy Server Interface 671 ++++ Control traffic diverted To a MIDCOM agent 672 ==== Snooped and optionally modified application specific 673 control traffic returning FROM the Out-of-Path agent 674 | 675 . private domain Boundary 676 | 678 Figure 3: Out-of-Path MIDCOM Agents for Middlebox Communication 680 6.0. Policy Server functions 682 The functional decomposition of the MIDCOM architecture assumes 683 the existence of a logical entity known as Policy Server, 684 responsible for performing authorization and related provisioning 685 services for the middlebox as depicted in figure 1. The Policy 686 server is a logical entity which may reside physically on a 687 middlebox or on a node external to the middlebox. The protocol 688 employed for communication between the middlebox and the policy 689 server is unrelated to the MIDCOM protocol. 691 Agents are pre-registered with a Policy Server for authorization to 692 gain access to a middlebox. The policy server maintains a list of 693 agents that are authorized to connect to each of the middleboxes the 694 policy server supports. The Policy server has no knowledge of 695 middlebox service and as such cannot help a middlebox with any of 696 the middlebox services and the resource authorization. 698 The policy server acts in an advisory capacity to a middlebox to 699 authorize or terminate authorization for an agent to gain 700 connectivity to the middlebox. The primary objective of a policy 701 server is to communicate agent authorization information so as to 702 ensure that the security and integrity of a middlebox is not 703 jeopardized. Specifically, the policy server should associate a 704 trust level with each agent attempting to connect to a middlebox 705 and provide a security profile. The policy server should be capable 706 of addressing cases when end-hosts are agents to the middle-box. 708 6.1. Authentication, Integrity and Confidentiality 710 Host authenticity and individual message security are two distinct 711 types of security considerations. Host authentication refers to 712 credentials required of a MIDCOM agent to authenticate itself to 713 the middlebox and vice versa. When authentication fails, the 714 middlebox MUST not process signaling requests received from the 715 agent that failed authentication. Two-way authentication should be 716 supported. In some cases, the 2-way authentication may be tightly 717 linked to the establishment of keys to protect subsequent traffic. 718 Two-way authentication is often required to prevent various active 719 attacks on the MIDCOM protocol and secure establishment of keying 720 material. 722 Security services such as authentication, data integrity, 723 confidentiality and replay protection may be adapted to secure 724 MIDCOM messages in an untrusted domain. Message authentication is 725 same as data origin authentication and is an affirmation that the 726 sender of the message is who it claims to be. Data integrity means 727 the whole truth and nothing but the truth. Confidentiality is 728 encryption of message with a key so that only those in possession 729 of the key can decipher the message content. Lastly, replay 730 protection is a form of sequence integrity so when an intruder 731 plays back a previously recorded sequence of messages, the 732 receiver of the replay messages will simply drop the replay 733 messages into bit-bucket. Certain applications of the MIDCOM 734 protocol might require support for non-repudiation as an option of 735 the data integrity service. Typically, support for non-repudiation 736 is required for billing, service level agreements, payment orders, 737 and receipts for delivery of service. 739 IPsec AH ([IPSEC-AH]) offers data-origin authentication, data 740 integrity and protection from message replay. IPsec ESP 741 ([IPSEC-ESP]) provides data-origin authentication to a lesser 742 degree (same as IPsec AH if the MIDCOM transport protocol turns out 743 to be TCP or UDP), message confidentiality, data integrity and 744 protection from replay. Besides the IPsec based protocols, there 745 are other security options as well. TLS based transport layer 746 security is one option. There are also many application-layer 747 security mechanisms available. Simple Source-address based 748 security is the least form of security in a trusted domain and 749 may be permitted to trusted hosts. 751 MIDCOM message security shall use existing standards, whenever the 752 existing standards satisfy the requirements. Security shall be 753 specified to minimize the impact on connections that do not use the 754 security option. Security should be designed to avoid introducing 755 and to minimize the impact of denial of service attacks. Some 756 security mechanisms and algorithms require substantial processing 757 or storage, in which case the security protocols should protect 758 themselves as well as against possible flooding attacks that 759 overwhelm the endpoint (i.e., the middlebox or the agent) with 760 such processing. For connection oriented protocols (such as TCP) 761 using security services, the security protocol should detect 762 premature closure or truncation attacks. 764 6.2. Registration and deregistration with a middlebox 766 Prior to giving MIDCOM agents access to the middlebox resources, 767 a registration process MUST take place. Registration is a 768 different process than establishing a transport connection. 769 The former requires exchanging agent profile information. The 770 latter refers to establishing a MIDCOM transport connection and 771 exchanging security credentials between an agent and a 772 middlebox. The latter uses the information from the former for 773 connection establishment. 775 Profile of a MIDCOM agent includes agent authorization policy (i.e, 776 session tuples for which the agent is authorized to act as ALG), 777 agent type (e.g., In-path or Out-of-Path), agent accessibility 778 profile (including any host level authentication information) and 779 security profile (i.e., security requirements for messages 780 exchanged between the middlebox and the agent). 782 MIDCOM agent profile may be pre-configured on the middlebox while 783 provisioning the middlebox function. Either the agent or the 784 middlebox can choose to initiate a connection prior to any data 785 traffic. Alternately, either party (middlebox or the MIDCOM agent) 786 may choose to initiate a connection only upon noticing the 787 application specific traffic. 789 Coupling MIDCOM agents with the middlebox resources requires 790 a means of reflecting that into the resource description table 791 of the middlebox. In the case of a firewall, for example, the 792 ACL tuple may me altered to reflect the optional ALG presence. 793 The revised ACL may look something like the following. 795 (, , , 796 , , , ) 798 The reader should note that this is an illustrative example and 799 not necessarily the actual definition of an ACL tuple. The formal 800 description of the ACL is yet to be devised. Agent accessibility 801 information should also be provisioned. For a MIDCOM agent, 802 accessibility information includes the IP address, trust level, 803 host authentication parameters and message authentication 804 parameters. Once a connection is established between a middlebox 805 and a MIDCOM agent, that connection should be usable with multiple 806 instances of the application(s), as appropriate. Note, all of this 807 could be captured in an agent profile for ease of management. 809 The technique described above is necessary for the pre-registration 810 of MIDCOM agents with the middlebox. However, it is possible to 811 retain the provisioning on middlebox unchanged, by requiring MIDCOM 812 agents to initiate the connection to middlebox. In such a case, the 813 agent should initiate the connection prior to the start of the 814 application. If the agent connection is delayed until after the 815 application has started, the agent might be unable to process the 816 control stream to permit the data connections. When Middlebox notices 817 an incoming MIDCOM connection, and the middlebox has no prior profile 818 of the MIDCOM agent, the middlebox will consult its Policy Server for 819 authenticity, authorization and trust guidelines for the connection. 821 At the end of the MIDCOM session, it should be possible for either 822 the middlebox or the agent to disconnect. MIDCOM session 823 disconnection may be prompted by a successful termination or 824 failure of some sort. 826 It should be possible for the agent to deregister itself from the 827 middlebox, which means that the agent is going out of service and 828 will not be available for further MIDCOM operations. Alternately, 829 a policy server may notify a middlebox that a particular MIDCOM 830 agent is no longer authorized for a particular set of sessions 831 any longer. Note, Policy Server notifying the middlebox is one of 832 many ways by which a middlebox could disconnect an agent. 834 7.0. MIDCOM Framework Illustration using an In-Path agent 836 In figure 3 below, we consider SIP application (Refer [SIP]) to 837 illustrate the operation of MIDCOM protocol. Specifically, the 838 application assumes a caller, external to a private domain, 839 initiates the call. Middlebox is assumed to be located at the 840 edge of the private domain. A SIP phone (SIP User Agent 841 Client/Server) inside the private domain is capable of receiving 842 calls from external SIP phones. The caller uses a SIP Proxy 843 node, located external to the private domain, as its outbound 844 proxy. No interior proxy is assumed for the callee. Lastly, the 845 external SIP proxy node is designated to host the MIDCOM agent 846 function. 848 Arrows 1 and 4 in the figure below refer to SIP call setup 849 exchange between the external SIP phone and the SIP proxy. 850 Arrows 6 and 7 refer to SIP call setup exchange between the SIP 851 proxy and the interior SIP phone and are assumed to be 852 traversing the middlebox. Arrows 2 and 3 below between the SIP 853 proxy and the middlebox refer to MIDCOM communication. Na and Nb 854 represent RTP/RTCP media traffic (Refer [RTP]) path in the 855 external network. Nc and Nd represent media traffic inside the 856 private domain. 858 _________ 859 --->| SIP |<-----\ 860 / | Proxy | \ 861 | |_________| | 862 1| | | 6| 863 | | | | 864 |4 |2 |3 |7 865 ______________ | | | | _____________ 866 | |<-/ _v_____^___ \->| | 867 | External | Na | | Nc | SIP Phone | 868 | SIP phone |>------->| MiddleBox |>------>| within | 869 | |<-------<|___________|<------<| Pvt. domain| 870 |____________| Nb Nd |____________| 872 Figure 4: MIDCOM framework illustration with In-Path SIP Proxy 874 As for the SIP application, we make the assumption that the 875 middlebox is pre-configured to accept SIP calls into the 876 private SIP phone. Specifically, this would imply that the 877 middlebox implementing firewall service is pre-configured to 878 permit SIP calls (destination TCP or UDP port number set to 879 5060) into the private phone. Likewise, middlebox implementing 880 NAPT service would have been pre-configured to provide a port 881 binding to permit incoming SIP calls to be redirected to the 882 specific private SIP phone. I.e., the INVITE from the external 883 caller is not made to the private IP address, but to the NAPT 884 external address. 886 The objective of the MIDCOM agent in the following illustration 887 is to merely permit the RTP/RTCP media stream (Refer [RTP]) 888 through the middlebox, using the MIDCOM protocol architecture 889 outlined in the document. RTP/RTCP media stream, When used in 890 conjunction with SIP will typically result in two independent 891 media sessions - one from the callee to the caller and another 892 from the caller to the callee. These media sessions are UDP based 893 and will use dynamic ports. The dynamic ports used for the media 894 stream are specified in the SDP section (Refer [SDP]) of SIP 895 payload message. The MIDCOM agent will parse the SDP section and 896 use the MIDCOM protocol to (a) open pinholes (i.e., permit RTP/RTCP 897 session tuples) in a middlebox implementing firewall service, or 898 (b) create PORT bindings and appropriately modify the SDP content to 899 permit the RTP/RTCP streams through a middlebox implementing NAT 900 service. The MIDCOM protocol should be sufficiently rich and 901 expressive to support the operations described under the timelines. 902 The examples do not show the timers maintained by the agent to 903 keep the firewall pinholes and NAT session descriptors and BINDs 904 from timing out. 906 Midcom agent Registration and connectivity between the Midcom 907 agent and the middlebox are not shown in the interest of 908 restricting the focus of the MIDCOM transactions to enabling the 909 middlebox to let the media stream through. Policy server is also 910 not shown in the diagram below or on the timelines for the same 911 reason. 913 The following subsections illustrate a typical timeline sequence 914 of operations that transpire with the various elements involved 915 in a SIP telephony application path. Each subsection is devoted 916 to a specific instantiation of a middlebox service - NAPT 917 (refer [NAT-TERM], [NAT-TRAD]), firewall and a combination of 918 both NAPT and firewall are considered. 920 7.1. Timeline flow - Middlebox implementing firewall service 922 In the following example, we will assume a middlebox implementing 923 a firewall service. We further assume that the middlebox is 924 pre-configured to permit SIP calls (destination TCP or UDP port 925 number set to 5060) into the private phone. The following timeline 926 illustrates the operations performed by the MIDCOM agent to permit 927 RTP/RTCP media stream through the middlebox. 929 The INVITE from the caller (external) is assumed to include the 930 SDP payload. You will note that the In-Path agent requests 931 the middlebox to permit the Pri-to-ext RTP/RTCP flows before the 932 INVITE is relayed to the callee. This is because, in SIP, the 933 calling party must be ready to receive the media when it sends 934 the INVITE with a session description. If the called party 935 (private phone) assumes this and sends "early media" before 936 sending the 200 OK response, the firewall will have blocked these 937 packets without this initial MIDCOM signaling from the agent. 939 SIP Phone SIP Proxy Middlebox SIP Phone 940 (External) (In-Path (FIREWALL (private) 941 MIDCOM agent) Service) | 942 | | | | 943 |----INVITE------>| | | 944 | | | | 945 | Identify end-2-end | | 946 | parameters (from Caller's | | 947 | SDP) for the pri-to-Ext | | 948 | RTP & RTCP sessions. | | 949 | (RTP1, RTCP1) | | 950 | | | | 951 | |+Permit RTP1, RTCP1 +>| | 952 | |<+RTP1, RTCP1 OKed++++| | 953 | | | | 954 | |--------INVITE---------------------->| 955 |<---100Trying----| | | 956 | | | | 957 | |<-----180 Ringing--------------------| 958 |<--180Ringing----| | | 959 | |<-------200 OK-----------------------| 960 | | | | 961 | Identify end-2-end | | 962 | parameters (from callee's | | 963 | SDP) for the Ext-to-Pri | | 964 | RTP and RTCP sessions. | | 965 | (RTP2, RTCP2) | | 966 | | | | 967 | |+Permit RTP2, RTCP2 +>| | 968 | |<+RTP2, RTCP2 OKed++++| | 969 | | | | 970 |<---200 OK ------| | | 971 |-------ACK------>| | | 972 | |-----------ACK---------------------->| 973 | | | | 974 |<===================RTP/RTCP==========================>| 975 | | | | 976 |-------BYE------>| | | 977 | |--------------------------BYE------->| 978 | | | | 979 | |<----------200 OK--------------------| 980 | | | | 981 | |++Cancel permits to | | 982 | | RTP1, RTCP1, RTP2, | | 983 | | and RTCP2 +++++++++>| | 984 | |<+RTP1, RTP2, RTCP1 & | | 985 | | RTCP2 cancelled ++++| | 986 | | | | 987 |<---200 OK-------| | | 988 | | | | 990 Legend: ++++ MIDCOM control traffic 991 ---- SIP control traffic 992 ==== RTP/RTCP media traffic 994 7.2. Timeline flow - Middlebox implementing NAPT service 996 In the following example, we will assume a middlebox implementing 997 NAPT service. We make the assumption that the middlebox is 998 pre-configured to redirect SIP calls to the specific private SIP 999 phone application. I.e., the INVITE from the external caller is 1000 not made to the private IP address, but to the NAPT external 1001 address. Let us say, the external phone's IP address is Ea, NAPT 1002 middlebox external Address is Ma and the internal SIP phone's 1003 private address is Pa. SIP calls to the private SIP phone will 1004 arrive as TCP/UDP sessions with destination address and port set 1005 to Ma and 5060 respectively. The middlebox will redirect these 1006 datagrams to the internal SIP phone. The following timeline 1007 will illustrate the operations necessary to be performed by the 1008 MIDCOM agent to permit the RTP/RTCP media stream through the 1009 middlebox. 1011 As with the previous example (section 7.1), INVITE from the 1012 caller (external) is assumed to include the SDP payload. 1013 You will note that the In-Path agent requests middlebox to create 1014 NAT session descriptors for the Pri-to-ext RTP/RTCP flows before 1015 the INVITE is relayed to the private SIP phone (for the same 1016 reasons as described in section 7.1). If the called party (private 1017 phone) sends "early media" before sending the 200 OK response, the 1018 NAPT middlebox will have blocked these packets without the 1019 initial MIDCOM signaling from the agent. Also, note that after 1020 the 200 OK is received by the proxy from the private phone, 1021 the agent requests the middlebox to allocate NAT session 1022 descriptors for the ext-to-pri RTP2 and RTCP2 flows, such that the 1023 ports assigned on the Ma for RTP2 and RTCP2 are contiguous. RTCP 1024 stream does not happen with a non-contiguous port. Lastly, you will 1025 note that even though each media stream (RTP1, RTCP1, RTP2 and 1026 RTCP2) is independent, they are all tied to the single SIP 1027 control session while the NAT session descriptors were being 1028 created. Finally, when the agent issues a terminate session bundle 1029 command for the SIP session, the middlebox is assumed to delete all 1030 associated media stream sessions automagically. 1032 Unlike firewall, NAT is stateful and strictly session oriented. 1033 The reader may refer [NAT-FRAMEWORK] for a detailed 1034 discussion of NAT managed stateful resources, including that of 1035 NAT session-descriptor and NAT BIND. 1037 SIP Phone SIP Proxy Middlebox SIP Phone 1038 (External) (In-Path (NAPT (Private) 1039 IP Addr:Ea MIDCOM agent) Service) IP addr:Pa 1040 | | IP addr:Ma | 1041 | | | | 1042 |----INVITE------>| | | 1043 | |++ Query Port-BIND | | 1044 | | for (Ma, 5060) +++>| | 1045 | |<+ Port-BIND reply | | 1046 | | for (Ma, 5060) ++++| | 1047 | | | | 1048 | |++ Query NAT Session | | 1049 | | Descriptor for | | 1050 | | Ea-to-Pa SIP flow+>| | 1051 | |<+ Ea-to-Pa SIP flow | | 1052 | | Session Descriptor+| | 1053 | | | | 1054 | Determine the Internal | | 1055 | IP address (Pa) | | 1056 | of the callee. | | 1057 | | | | 1058 | Identify UDP port numbers | | 1059 | on Ea (Eport1, Eport1+1) | | 1060 | for pri-to-ext RTP & RTCP | | 1061 | sessions (RTP1, RTCP1) | | 1062 | | | | 1063 | |++Create NAT Session | | 1064 | | descriptors for | | 1065 | | RTP1, RTCP1; Set | | 1066 | | parent session to | | 1067 | | SIP-ctrl session ++>| | 1068 | |<+RTP1, RTCP1 session | | 1069 | | descriptors created+| | 1070 | | | | 1071 | | |..redirected..| 1072 | |--------INVITE--------|------------->| 1073 |<---100Trying----| | | 1074 | | | | 1075 | |<-----180Ringing---------------------| 1076 | | | | 1077 |<--180Ringing----| | | 1078 | |<-------200 OK-----------------------| 1079 | | | | 1080 | Identify UDP port numbers | | 1081 | on Pa (Pport2, Pport2+1) | | 1082 | for ext-to-pri RTP & RTCP | | 1083 | sessions (RTP2, RTCP2) | | 1084 | | | | 1085 | |++Create consecutive | | 1086 | | port BINDs on Ma | | 1087 | | for (Pa, Pport2), | | 1088 | | (Pa, Pport2+1) ++++>| | 1089 | |<+Port BINDs created++| | 1090 | | | | 1091 | |++Create NAT Session | | 1092 | | descriptors for | | 1093 | | RTP2, RTCP2; Set | | 1094 | | parent session to | | 1095 | | SIP-ctrl session ++>| | 1096 | |<+RTP2, RTCP2 session | | 1097 | | descriptors created+| | 1098 | | | | 1099 | Modify the SDP | | 1100 | parameters in "200 OK" | | 1101 | with NAPT PORT-BIND | | 1102 | for the RTP2 port on Ma. | | 1103 | | | | 1104 |<---200 OK ------| | | 1105 | | | | 1106 |-------ACK------>| | | 1107 | | | | 1108 | Modify IP addresses | | 1109 | appropriately in the SIP | | 1110 | header (e.g., To, from, | | 1111 | Via, contact fields) | | 1112 | | |..redirected..| 1113 | |-----------ACK--------|------------->| 1114 | | | | 1115 | | | | 1116 |<===================RTP/RTCP============|=============>| 1117 | | | | 1118 |-------BYE------>| | | 1119 | | | | 1120 | Modify IP addresses | | 1121 | appropriately in the | | 1122 | SIP header. | | 1123 | | | | 1124 | |----------------------|-----BYE----->| 1125 | | | | 1126 | |<----------200 OK--------------------| 1127 | | | | 1128 | |+++Terminate the SIP | | 1129 | | Session bundle +++>| | 1130 | |<++SIP Session bundle | | 1131 | | terminated ++++++++| | 1132 | | | | 1133 | Modify SDP | | 1134 | parameters in "200 OK" | | 1135 | | | | 1136 |<---200 OK-------| | | 1137 | | | | 1139 Legend: ++++ MIDCOM control traffic 1140 ---- SIP control traffic 1141 ==== RTP/RTCP media traffic 1143 7.3. Timeline flow - Middlebox implementing NAPT and firewall 1145 In the following example, we will assume a middlebox 1146 implementing a combination of a firewall and a stateful NAPT 1147 service. We make the assumption that the NAPT function is 1148 configured to translate the IP and TCP headers of the initial 1149 SIP session into the private SIP phone and the firewall 1150 function is configured to permit the initial SIP session. 1152 In the following time line, it may be noted that the firewall 1153 description is based on packet fields on the wire (ex: as seen 1154 on the external interface of the middlebox). In order to 1155 ensure correct behavior of the individual services, you will 1156 notice that NAT specific MIDCOM operations precede firewall 1157 specific operations on the MIDCOM agent. This is noticeable in 1158 the time line below when the MIDCOM agent processes the 1159 "200 OK" from the private SIP phone. The MIDCOM agent initially 1160 requests the NAT service on the middlebox to set up port-BIND 1161 and session-descriptors for the media stream in both directions. 1162 Subsequent to that, the MIDCOM agent determines the session 1163 parameters (i.e, the dynamic UDP ports) for the media stream, 1164 as viewed by the external interface and requests the firewall 1165 service on the middlebox to permit those sessions through. 1167 SIP Phone SIP Proxy Middlebox SIP Phone 1168 (External) (In-Path (NAPT & (Private) 1169 IP Addr:Ea MIDCOM agent) firewall IP addr:Pa 1170 | | Services) | 1171 | | IP addr:Ma | 1172 | | | | 1173 |----INVITE------>| | | 1174 | |++ Query Port-BIND | | 1175 | | for (Ma, 5060) +++>| | 1176 | |<+ Port-BIND reply | | 1177 | | for (Ma, 5060) ++++| | 1178 | | | | 1179 | |++ Query NAT Session | | 1180 | | Descriptor for | | 1181 | | Ea-to-Pa SIP flow+>| | 1182 | |<+ Ea-to-Pa SIP flow | | 1183 | | Session Descriptor+| | 1184 | | | | 1185 | Determine the Internal | | 1186 | IP address (Pa) | | 1187 | of the callee. | | 1188 | | | | 1189 | Identify UDP port numbers | | 1190 | on Ea (Eport1, Eport1+1) | | 1191 | for pri-to-ext RTP & RTCP | | 1192 | sessions (RTP1, RTCP1) | | 1193 | | | | 1194 | |++Create NAT Session | | 1195 | | descriptors for | | 1196 | | RTP1, RTCP1; Set the| | 1197 | | parent session to | | 1198 | | point to SIP flow++>| | 1199 | |<+RTP1, RTCP1 session | | 1200 | | descriptors created+| | 1201 | | | | 1202 | |++Permit RTP1 & RTCP1 | | 1203 | | sessions External to| | 1204 | | middlebox, namely | | 1205 | | Ma to Ea:Eport1, | | 1206 | | Ma to Ea:Eport1+1 | | 1207 | | sessions ++++++++++>| | 1208 | |<+Ma to Ea:Eport1, | | 1209 | | Ma to Ea:Eport1+1 | | 1210 | | sessions OKed ++++++| | 1211 | | | | 1212 | | |..redirected..| 1213 | |--------INVITE--------|------------->| 1214 |<---100Trying----| | | 1215 | | | | 1216 | |<-----180Ringing---------------------| 1217 | | | | 1218 | | | | 1219 |<--180Ringing----| | | 1220 | |<-------200 OK-----------------------| 1221 | | | | 1222 | Identify UDP port numbers | | 1223 | on Pa (Pport2, Pport2+1) | | 1224 | for ext-to-pri RTP & RTCP | | 1225 | sessions (RTP2, RTCP2) | | 1226 | | | | 1227 | |++Create consecutive | | 1228 | | port BINDs on Ma | | 1229 | | for (Pa, Pport2), | | 1230 | | (Pa, Pport2+1) ++++>| | 1231 | |<+Port BINDs created | | 1232 | | on Ma as (Mport2, | | 1233 | | Mport2+1) ++++++++++| | 1234 | | | | 1235 | |++Create NAT Session | | 1236 | | descriptors for | | 1237 | | RTP2, RTCP2; Set the| | 1238 | | parent session to | | 1239 | | point to SIP flow++>| | 1240 | |<+RTP2, RTCP2 session | | 1241 | | descriptors created+| | 1242 | | | | 1243 | Modify the SDP | | 1244 | parameters in "200 OK" | | 1245 | with NAPT PORT-BIND | | 1246 | for RTP2 port on Ma. | | 1247 | | | | 1248 | |++Permit RTP2 & RTCP2 | | 1249 | | sessions External | | 1250 | | middlebox, namely | | 1251 | | Ea to Ma:Mport2, | | 1252 | | Ea to Ma:Mport2+1 | | 1253 | | sessions ++++++++++>| | 1254 | |<+Ea to Ma:Mport2, | | 1255 | | Ea to Ma:Mport2 | | 1256 | | sessions OKed ++++++| | 1257 | | | | 1258 |<---200 OK ------| | | 1259 | | | | 1260 |-------ACK------>| | | 1261 | | |..redirected..| 1262 | |-----------ACK--------|------------->| 1263 | | | | 1264 | | | | 1265 |<===================RTP/RTCP============|=============>| 1266 | | | | 1267 |-------BYE------>| | | 1268 | | | | 1269 | Modify SDP payload | | 1270 | parameters in BYE | | 1271 | | | | 1272 | |----------------------|-----BYE----->| 1273 | | | | 1274 | |<----------200 OK--------------------| 1275 | | | | 1276 | |+++Terminate the SIP | | 1277 | | Session bundle +++>| | 1278 | |<++SIP Session bundle | | 1279 | | terminated ++++++++| | 1280 | | | | 1281 | |++Cancel permits to | | 1282 | | sessions External | | 1283 | | middlebox, namely | | 1284 | | Ma to Ea:Eport1, | | 1285 | | Ma to Ea:Eport1+1 | | 1286 | | Ea to Ma:Mport2, | | 1287 | | Ea to Ma:Mport2+1 | | 1288 | | sessions ++++++++++>| | 1289 | |<+Removed permits to | | 1290 | | sessions listed ++++| | 1291 | | | | 1292 | Modify SDP | | 1293 | parameters in "200 OK" | | 1294 | | | | 1295 |<---200 OK-------| | | 1296 | | | | 1298 Legend: ++++ MIDCOM control traffic 1299 ---- SIP control traffic 1300 ==== RTP/RTCP media traffic 1302 8.0. MIDCOM framework illustration with an Out-Of-path FTP Agent 1304 In the following figure, an FTP client inside a private domain 1305 connects via a middlebox to an external FTP server. The middlebox 1306 is assumed to implement NAPT and firewall functions. The FTP 1307 traffic is addressed directly to the external FTP server. The Arrow 1308 labeled 1 indicates a registration via the MIDCOM protocol in 1309 which the Out-of-Path FTP agent indicates that it would like to 1310 receive TCP traffic directed to or from port 21 (FTP control). The 1311 OOP agent may be located either inside the private domain or 1312 external to the domain. 1314 The FTP control traffic traversing the middlebox is diverted by 1315 the middlebox to the Out-of-Path FTP agent for FTP control payload 1316 processing. Diverted control traffic is indicated by Arrow 2. The 1317 OOP agent parses the FTP control commands and responses and possibly 1318 modifies, as appropriate and forwards the traffic over to the server 1319 and/or the client. Neither of the end-hosts is aware of the OOP Agent 1320 or the middlebox in transit. 1322 At some point, the Client sends a PORT command to the Server, 1323 indicating that the Server should create a TCP connection from the 1324 Server to the Client. This port command specifies an IP address and 1325 port number to which the Server should connect. The IP address may 1326 be a private IP address, if the client is located in a privately 1327 addressed domain. 1329 The OOP agent parses the PORT command, and carries out appropriate 1330 MIDCOM transactions (Arrow 4) to discover any changes to the IP 1331 address required, to request a new NAPT port binding if necessary, 1332 and to open a suitable pinhole allowing the connection from the 1333 Server to the dynamically allocated port number on the Client to 1334 succeed. The (perhaps modified) PORT command is then sent on to the 1335 Server, which responds by connecting to the indicated IP address and 1336 port, which will now flow through the middlebox to the Client. 1338 The example does not show the timers maintained by the agent to 1339 keep the firewall pinholes and NAT session descriptors and BINDs 1340 from timing out. Readers are urged to refer [NAT-FRAMEWORK] for 1341 a detailed illustration of how an OOP agent could interface with 1342 the NAT-only middlebox. 1344 --------------- 1345 | Out-of-Path | 1346 | (OOP) FTP | 1347 | Agent | 1348 |_____________| 1349 | ^ | | 1350 | | | | 1351 |1 |2 |3 |4 1352 ______________ | | | | _____________ 1353 | | _v__|__v__v_ | | 1354 | FTP client | Ctrl | | Ctrl | External | 1355 | within the |<------->| MiddleBox |<------>| FTP Server | 1356 | Pvt. domain|<------->|___________|<------>| | 1357 |____________| Data Data |____________| 1359 Ctrl - indicates the FTP control traffic, which 1360 is transparently diverted to the OOP agent (2 and 3) 1361 Data - indicates the FTP data traffic, which flows 1362 directly through the middlebox between the FTP 1363 end hosts (i.e., FTP client and Server) 1365 Figure 5: MIDCOM framework illustration Out-of-Path FTP agent 1367 8.1. Timeline Flow - Middlebox implementing NAPT and Firewall 1369 In the following figure, an end-host inside the private network 1370 at address(pa) 10.0.0.4 wishes to communicate with an external FTP 1371 server with an IP address Ea. The Middlebox provides public IP 1372 address(Ma) 209.46.41.66 for external communication by private 1373 hosts. 1375 The middlebox diverts the FTP control traffic to the OOP agent. 1376 The OOP agent, in turn, reviews the datagrams and optionally 1377 modify as appropriate and redirects the datagrams right back to 1378 the middlebox. The OOP agent may need to update even the TCP 1379 SYNs and ACKs (i.e., datagrams with no application specific 1380 payload) in the event the agent had to rewrite the address 1381 content in the payload and the payload length changed as a result. 1383 FTP-client OOP FTP Middlebox (NAPT & FTP Server 1384 (Private) Agent Firewall Services) (External) 1385 IP addr(Pa): | IP addr(Ma): IP addr: Ea 1386 10.0.0.4 | 209.46.41.66 | 1387 | | | | 1388 | | | | 1389 | |++Attach as FTP ALG+++>| | 1390 | | | | 1391 | |<+++++ OK +++++++++++++| | 1392 | | | | 1393 | The OOP FTP Agent attaches with middlebox & | 1394 | is authorized to process FTP control | 1395 | traffic from private hosts (or any set | 1396 | of hosts adhering to a certain policy) | 1397 | | | | 1398 | | | | 1399 The FTP client connects to the external FTP server. The middlebox 1400 would have created a NAT Port-BIND and an FTP control session 1401 resource with the appropriate translation parameters. 1402 | | | | 1403 | PORT 10,0,0,4,4,9 | | 1404 |--------------------------------------| | 1405 | | | | 1406 | |<## Ctrl-Pkt diverted #| | 1407 | | | | 1408 | |++Query NAT Session | | 1409 | | Descriptor for | | 1410 | | Pa-to-Ea FTP flow+++>| | 1411 | | | | 1412 | |<+Pa-to-Ea FTP flow | | 1413 | | Session Descriptor+++| | 1414 | | | | 1415 | |++Create NAT port-BIND | | 1416 | | for (Pa, 1033) +++++>| | 1417 | | | | 1418 | |<+Port BINDs created | | 1419 | | with (Ma, 15324)+++++| | 1420 | | | | 1421 | |++Create NAT Session | | 1422 | | descriptor for the | | 1423 | | Data session from Ea | | 1424 | | to (Ma, 15324);Set | | 1425 | | Parent session to | | 1426 | | FTP-Ctrl session +++>| | 1427 | | | | 1428 | |<+FTP-Data session | | 1429 | | descriptor created+++| | 1430 | | | | 1431 | |++Permit FTP data | | 1432 | | session from Ea to | | 1433 | | (Ma, 15324)+++++++++>| | 1434 | | | | 1435 | |<+Data session OKed++++| | 1436 | | | | 1437 | |### Modified Control | | 1438 | | Pkt forwarded #######################>| 1439 | | | | 1440 |<===FTP Data traffic between Pa & Ea==|=================>| 1441 | | | | 1442 | | | | 1444 Legend: ++++ MIDCOM control traffic 1445 ##### Diverted datagrams between 1446 ---- FTP control traffic 1447 ==== FTP data traffic 1449 The above flow does not indicate all packets as diverted, only 1450 the important ones (e.g. the datagram with the PORT command in 1451 the payload). It is safe to assume that all control packets are 1452 diverted from the middlebox to the OOP Agent via the datagram 1453 diversion component of the middlebox. 1455 Note that the FTP data traffic is not diverted to the OOP Agent. 1456 This is because the OOP agent does not assign a diversion function 1457 associated with the data session while at the instance creating the 1458 FTP-Data session. This is an essential feature, since we allow the 1459 middlebox to move the data about, while the Agent intervention is 1460 limited just to the control session. 1462 9.0. Operational considerations 1464 9.1. Multiple MIDCOM connections between agents and middlebox 1466 A middlebox cannot be assumed to be a simple device 1467 implementing just one middlebox function and no more than a 1468 couple of interfaces. Middleboxes often combine multiple 1469 intermediate functions into the same device and have the 1470 ability to provision individual interfaces of the same device 1471 with different sets of functions and varied provisioning for 1472 the same function across the interfaces. 1474 As such, a MIDCOM agent ought to be able to have a single 1475 MIDCOM connection with a middlebox and use the MIDCOM 1476 interface on the middlebox to interface with different 1477 services on the same middlebox interface. 1479 9.2. MIDCOM agent registration with a middlebox 1481 A MIDCOM agent may be pre-configured on a middlebox as a 1482 trusted entity. In the case where a MIDCOM agent is not 1483 pre-configured, a policy server should be made available 1484 to the middlebox, so the middlebox can consult the Policy 1485 Server for authorization to accept requests from the agent. 1486 A middlebox should be capable of connecting to more than 1487 a single MIDCOM agent. 1489 9.3. Asynchronous notification to MIDCOM agents 1491 Asynchronous notification by the middlebox to a MIDCOM agent 1492 can be useful for events such as Session creation, Session 1493 termination, MIDCOM protocol failure, Middlebox function 1494 failure or any other significant event. Independently, ICMP 1495 error codes can also be useful to notify transport layer 1496 failures to the agents. 1498 In addition, periodic notification of statistics update would 1499 also be a useful function that would be beneficial to 1500 certain types of agents. 1502 9.4. Packet redirection 1503 During connection establishment between an agent and a middlebox, 1504 the agent identifies itself as in-path (or) Out-of-Path. The 1505 middlebox takes no additional action to redirect a packet, if the 1506 agent is in-path. If the agent is Out-of-Path, the middlebox will 1507 be required to have a datagram diverter function that diverts 1508 datagrams to the out-of-path agent. The datagram diverter function 1509 on a middlebox, however, is not a requirement when the middlebox 1510 chooses not to support OOP agents. 1512 The OOP agent should be capable of returning processed datagrams 1513 to the middlebox point of origin or forward to the destination. 1514 The middlebox should in turn forward the processed datagrams 1515 without subjecting to any middlebox services the second time 1516 around. I.e., A datagram should not be diverted back to the OOP 1517 agent the second time around. Failing this, the datagram could 1518 simply recycle between the two entities. 1520 The datagram diverter function is an internal implementation 1521 issue for the middlebox and is unrelated to the MIDCOM protocol. 1522 One approach to datagram diversion might be to encapsulate 1523 datagrams (both diverted and processed) in a tunnel during 1524 traversal between the agent and the middlebox. Another approach 1525 might be to dedicate an interface on the middlebox for the 1526 purpose. There may be other proprietary approaches. 1528 9.5. Middleboxes supporting multiple services 1530 A middlebox could be implementing a variety of services (e.g. NAT 1531 and firewall) in the same box. Some of these services might have 1532 inter-dependency on shared resources and sequence of operation. 1533 Others may be independent of each other. Generally speaking, 1534 the sequence in which these function operations may be performed 1535 on datagrams is not within the scope of this document. 1537 In the case of a middlebox implementing NAT and firewall 1538 services, it is safe to state that the NAT operation will precede 1539 firewall on the egress and will follow firewall on the ingress. 1540 Further, firewall access control lists used by a firewall are 1541 assumed to be based on session parameters as seen on the 1542 interface supporting firewall service. 1544 9.6. Signaling and Data traffic 1546 The class of applications the MIDCOM architecture is addressing 1547 focus around applications that have a combination of one or more 1548 signaling and data traffic sessions. The signaling 1549 may be done out-of-band using a dedicated stand-alone session 1550 or may be done in-band with data session. Alternately, signaling 1551 may also be done as a combination of both stand-alone and 1552 in-band sessions. 1554 SIP is an example of an application based on distinct signaling 1555 and data sessions. SIP signaling session is used for call setup 1556 between a caller and a callee. MIDCOM agent may be required to 1557 examine/modify SIP payload content to administer the middlebox 1558 so as to let the media streams (RTP/RTCP based) through. MIDCOM 1559 agent is not required to intervene in the data traffic. 1561 Signaling and context specific Header information is sent in-band 1562 within the same data stream for applications such as HTTP embedded 1563 applications, sun-RPC (embedding a variety of NFS apps), Oracle 1564 transactions (embedding oracle SQL+, MS ODBC, Peoplesoft) etc. 1566 H.323 is an example of application that sends signaling in both 1567 dedicated stand-alone session as well as in conjunction with data. 1568 Q.931 traffic traverses middleboxes by virtue of static policy, 1569 no MIDCOM control needed. Q.931 also negotiates ports for an 1570 H.245 TCP stream. A MIDCOM agent is required to examine/modify 1571 the contents of the H.245 so that H.245 can traverse it. 1573 H.245 traverses the middlebox and also carries Open Logical 1574 Channel information for media data. So the MIDCOM agent is once 1575 again required to examine/modify the payload content needs to 1576 let the media traffic flow. 1578 The MIDCOM architecture takes into consideration, supporting 1579 applications with independent signaling and data sessions as 1580 well as applications that have signaling and data communicated 1581 over the same session. 1583 In the cases where signaling is done on a single stand-alone 1584 session, it is desirable to have a MIDCOM agent interpret the 1585 signaling stream and program the middlebox (that transits the 1586 data stream) so as to let the data traffic through uninterrupted. 1588 10. Applicability Statement 1590 Middleboxes may be stationed in a number of topologies. However, the 1591 signaling framework outlined in this document may be limited to only 1592 those middleboxes that are located in a DMZ (De-Militarized Zone) at 1593 the edge of a private domain, connecting to the Internet. 1594 Specifically, the assumption is that you have a single middlebox 1595 (running NAT or firewall) along the application route. Discovery of 1596 middlebox along application route is outside the scope of this 1597 document. It is conceivable to have middleboxes located between 1598 departments within the same domain or inside service provider's 1599 domain and so forth. However, care must be taken to review each 1600 individual scenario and determine the applicability on a 1601 case-by-case basis. 1603 The applicability may also be illustrated as follows. Real-time and 1604 streaming applications such as Voice-Over-IP and peer-to-peer 1605 applications such as Napster and Netmeeting require administering 1606 firewall and NAT middleboxes to let their media streams reach hosts 1607 inside a private domain. The requirements are in the form of 1608 establishing a "pin-hole" to permit a TCP/UDP session (the port 1609 parameters of which are dynamically determined) through a firewall 1610 or retain an address/port bind in the NAT device to permit 1611 connections to a port. These requirements are met by current 1612 generation middleboxes using adhoc methods, such as embedding 1613 application intelligence within a middlebox to identify the dynamic 1614 session parameters and administering the middlebox internally as 1615 appropriate. The objective of the MIDCOM architecture is to create 1616 a unified, standard way to exercise this functionality, currently 1617 existing in an ad-hoc fashion in some of the middleboxes. 1619 By adopting MIDCOM architecture, middleboxes will be able to 1620 support newer applications they have not been able to support thus 1621 far. MIDCOM architecture does not and MUST not, in anyway, change 1622 the fundamental characteristic of the services supported on the 1623 middlebox. 1625 Typically, organizations shield a majority of their corporate 1626 resources (such as end-hosts) from visibility to the external 1627 network by the use of a De-Militarized Zone (DMZ) at the domain 1628 edge. Only a portion of these hosts are allowed to be accessed by 1629 the external world. The remaining hosts and their names are unique 1630 to the private domain. Hosts visible to the external world and the 1631 authoritative name server that maps their names to network 1632 addresses are often configured within a DMZ (De-Militarized Zone) 1633 in front of a firewall. Hosts and middleboxes within DMZ are 1634 referred to as DMZ nodes. 1636 Figure 4 below illustrates configuration of a private domain with 1637 a DMZ at its edge. Actual configurations may vary. Internal hosts 1638 are accessed only by users inside the domain. Middleboxes, 1639 located in the DMZ may be accessed by agents inside or outside 1640 the domain. 1642 \ | / 1643 +-----------------------+ 1644 |Service Provider Router| 1645 +-----------------------+ 1646 WAN | 1647 Stub A .........|\|.... 1648 | 1649 +---------------+ 1650 | NAT Middlebox | 1651 +---------------+ 1652 | 1653 | DMZ - Network 1654 ------------------------------------------------------------ 1655 | | | | | 1656 +--+ +--+ +--+ +--+ +-----------+ 1657 |__| |__| |__| |__| | Firewall | 1658 /____\ /____\ /____\ /____\ | Middlebox | 1659 DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web +-----------+ 1660 Server Server etc. | 1661 | 1662 Internal Hosts (inside the private domain) | 1663 ------------------------------------------------------------ 1664 | | | | 1665 +--+ +--+ +--+ +--+ 1666 |__| |__| |__| |__| 1667 /____\ /____\ /____\ /____\ 1668 Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server 1670 Figure 6: DMZ network configuration of a private domain. 1672 11. Acknowledgements 1674 The authors wish to thank Christian Huitema, Joon Maeng, Jon 1675 Peterson, Mike Fisk, Matt Holdrege, Melinda Shore, Paul Sijben, 1676 Philip Mart, Scott Brim and Richard Swale for their valuable 1677 critique, advice and input on an earlier rough version of this 1678 document. The authors owe special thanks to Eliot Lear for 1679 kick-starting the e-mail discussion on use-case scenarios with a 1680 SIP application flow diagram through a middlebox. Much thanks to 1681 Bob Penfield, Cedric Aoun, Christopher Martin, Eric Fleischman, 1682 George Michaelson, Wanqun Bao and others in the MIDCOM work group 1683 for their very detailed feedback on a variety of topics and 1684 adding clarity to the discussion. Last, but not the least, the 1685 authors owe much thanks to Melinda Shore for her continued 1686 support, critique and feedback throughout in bringing out fine 1687 subtleties and helping to make the document a better read. 1689 12. Security Considerations 1691 [SEC-GUIDE] defines security goals as either communication 1692 security related or systems security related. While the latter 1693 is important and should be addressed as part of a comprehensive 1694 security solution, it is considered to be outside the scope of 1695 this document. This section predominantly addresses what is 1696 required to ensure secure access to the middlebox. 1698 The premise of middlebox operation fundamentally requires 1699 stateful inspection of data in the clear. This compromises the 1700 confidentiality requirement in some environments. Further, 1701 Updating transport headers and rewriting application payload 1702 data in some cases by NAT prevents the use of integrity 1703 protection on some data streams traversing NAT middleboxes. 1704 Clearly, this can pose a significant security threat to the 1705 application in an untrusted transport domain. 1707 However, the MIDCOM protocol removes the need for a middlebox 1708 to inspect or manipulate data. This in turn allows applications 1709 to better protect themselves end-to-end with the aid of a trusted 1710 MIDCOM agent. This is especially the case when the agent is 1711 resident on the end-host. When an agent has the same end-to-end 1712 ability as the end-host to interpret encrypted and integrity 1713 protected data, data transiting a middlebox can be encrypted and 1714 integrity protected. The MIDCOM agent will still be able to 1715 interpret the data and simply notify the middlebox to open holes, 1716 install NAT table entries, etc. 1718 Security between a MIDCOM agent and a middlebox has a number of 1719 components. Authorization, authentication, integrity and 1720 confidentiality. Authorization refers to whether a particular 1721 agent is authorized to signal middlebox with requests for one or 1722 more applications adhering to a certain policy profile. Failing the 1723 authorization process might indicate resource theft attempt or 1724 failure due to administrative and/or credential deficiencies. In 1725 either case, the middlebox should take the proper measures to 1726 audit/log such attempts and consult its designated policy server 1727 for the required action if the middlebox is configured with one. 1728 Alternatively, the middlebox may resort to a default service deny 1729 policy when a midcom agent fails to prompt the required 1730 credentials. Section 6 discusses the middlebox-policy server 1731 interactions in view of policy decisions. 1733 Authentication refers to confirming the identity of originator 1734 for all datagrams received from the originator. Lack of strong 1735 credentials for authentication of MIDCOM messages between an agent 1736 and a middlebox can seriously jeopardize the fundamental service 1737 rendered by the middlebox. A consequence of not authenticating an 1738 agent would be that an attacker could spoof the identity of a 1739 "legitimate" agent and open holes in the firewall. Another would 1740 be that it could otherwise manipulate state on a middlebox, 1741 creating a denial-of-service attack by closing needed pinholes or 1742 filling up a NAT table. A consequence of not authenticating the 1743 middlebox to an agent is that an attacker could pose as a 1744 middlebox and respond to NAT requests in a manner that would divert 1745 data to the attacker. Failing to submit the required/valid 1746 credentials once challenged may indicate a replay attack and in 1747 which case a proper action is required by the middlebox such as 1748 auditing, logging, consulting its designated policy server to 1749 reflect such failure. 1751 Integrity is required to ensure that a MIDCOM message has not been 1752 accidentally or maliciously altered or destroyed. Result of a lack 1753 of data integrity enforcement in an untrusted environment could be 1754 that an imposter will alter the messages sent by an agent and 1755 bring the middlebox to a halt or cause a denial of service for the 1756 application the agent is attempting to enable. 1758 Confidentiality of MIDCOM messages ensure that the signaling data 1759 is accessible only to the authorized entities. When a middlebox 1760 agent is deployed in an untrusted environment, lack of 1761 confidentiality will allow an intruder to perform traffic flow 1762 analysis and snoop the middlebox resources. The intruder could 1763 cannibalize a lesser secure MIDCOM connection and destroy or 1764 compromise the middlebox resources he uncovered on other 1765 connections. Needless to say, the least secure MIDCOM connection 1766 will become the achilles heel and make the middlebox vulnerable 1767 to security attacks. 1769 Lastly, there can be security vulnerability to the applications 1770 traversing a middlebox when a resource on a middlebox is controlled 1771 by multiple external agents. A middlebox service may be abruptly 1772 disrupted due to malicious manipulation or incorrect implementation 1773 of the middlebox or its agents of a certain shared resource by an 1774 agent purporting to offer ALG service for a different middlebox 1775 function. Care must be taken in the protocol design to ensure that 1776 agents for one function do not abruptly step over resources impacting 1777 a different function. Alternately, the severity of such 1778 manifestations could be lessened when a single MIDCOM agent is 1779 responsible for supporting all the middlebox services for an 1780 application due to the reduced complexity and synchronization effort 1781 in managing the middlebox resources. 1783 REFERENCES 1785 [IETF-STD] Bradner, S., " The Internet Standards Process -- 1786 Revision 3", RFC 1602, IETF, October 1996. 1788 [SIP] Handley, M., H. Schulzrinne, E. Schooler, and 1789 J. Rosenberg, "SIP: Session Initiation Protocol", 1790 RFC 2543, IETF, March 1999. 1792 [SDP] Handley, M., and Jacobson, V., "SDP: session 1793 description protocol", RFC 2327, IETF, April 1998. 1795 [H.323] ITU-T Recommendation H.323. "Packet-based Multimedia 1796 Communications Systems," 1998. 1798 [RTP] Schulzrinne, H., S. Casner, R. Frederick, and V. Jacobson, 1799 "RTP: A Transport Protocol for Real-Time Applications", 1800 RFC 1889, IETF, January 1996. 1802 [RTSP] Schulzrinne, H., A. Rao, R. Lanphier: "Real Time 1803 Streaming Protocol", RFC 2326, IETF, April 1998. 1805 [FTP] J. Postel, J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", 1806 RFC 959 1808 [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address 1809 Translator (NAT) Terminology and Considerations", 1810 RFC 2663, August 1999. 1812 [NAT-TRAD] Srisuresh, P. and Egevang, K., "Traditional IP Network 1813 Address Translator (Traditional NAT)", RFC 3022, 1814 January 2001. 1816 [NAT-COMP] Holdrege, M. and Srisuresh, P., "Protocol Complications 1817 with the IP Network Address Translator", RFC 3027, 1818 January 2001. 1820 [NAT-PT] Tsirtsis, G. and Srisuresh, P., "Network Address 1821 Translation - Protocol Translation (NAT-PT)", 1822 RFC 2766, February 2000. 1824 [NAT-FRAMEWORK] Srisuresh, P., "Framework for interfacing with 1825 Network Address Translator", Work in progress, April 1826 2001, 1828 [MIDCOM-REQ] Swale, R.P., Mart, P.A. and Sijben, P., "Requirements 1829 for the MIDCOM protocol", work in progress, April 2001, 1830 1832 [APPL-ID] Bernet, Y. and Pabbati, R., "Application and Sub 1833 Application Identity Policy Element for Use with 1834 RSVP", RFC 2872, June 2000. 1836 [RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., 1837 de Groot, G. and E. Lear, "Address Allocation for 1838 Private Internets", BCP 5, RFC 1918, February 1996. 1840 [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", 1841 RFC 1700 1843 [IPsec-AH] Kent, S., and R. Atkinson, "IP Authentication 1844 Header", RFC 2402, November 1998. 1846 [IPsec-ESP] Kent, S., and R. Atkinson, "IP Encapsulating 1847 Security Payload (ESP)", RFC 2406, November 1998. 1849 [TLS] Dierks, T., and Allen, C., "The TLS Protocol 1850 Version 1.0", RFC 2246, January 1999. 1852 [SEC-GUIDE] Rescorla, E., and B. Korver, "Guidlines for Writing 1853 RFC Text on Security Considerations", Work in Progress, 1854 March 2001, 1856 Authors' Addresses 1858 Pyda Srisuresh 1859 Jasmine Networks 1860 3061 Zanker Road, Suite B 1861 San Jose, CA 95134 1862 U.S.A. 1863 EMail: srisuresh@yahoo.com 1865 Jiri Kuthan 1866 GMD Fokus 1867 Kaiserin-Augusta-Allee 31 1868 D-10589 Berlin, Germany 1869 E-mail: kuthan@fokus.gmd.de 1871 Jonathan Rosenberg 1872 dynamicsoft 1873 200 Executive Drive 1874 Suite 120 1875 West Orange, NJ 07052 1876 U.S.A. 1877 email: jdrosen@dynamicsoft.com 1879 Andrew Molitor 1880 Aravox technologies 1881 4201 Lexington Avenue North, Suite 1105 1882 Arden Hills, MN 55126 1883 U.S.A. 1884 voice: (651) 256-2700 1885 email: amolitor@visi.com 1887 Abdallah Rayhan 1888 P.O. Box 3511 Stn C 1889 Ottawa, ON, Canada K1Y 4H7 1890 eMail: ar_rayhan@yahoo.ca