idnits 2.17.1 draft-ietf-midcom-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document 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 are 2 instances of lines with control characters in the document. ** 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 267: '... communication protocol MUST allow for...' RFC 2119 keyword, line 465: '... agents MUST explicitly redirect app...' RFC 2119 keyword, line 495: '...s, the middlebox MUST not process sign...' RFC 2119 keyword, line 514: '...middlebox, a registration process MUST...' RFC 2119 keyword, line 516: '... SHOULD initiate the registration pr...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 167 has weird spacing: '...ress to provi...' == Line 293 has weird spacing: '...unction attri...' == Line 752 has weird spacing: '...ecurity consi...' == 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 authentication are two distinct types of authentications to consider. Host authentication refers to credentials required of a MIDCOM agent to authenticate itself to the middlebox and optionally that of the middlebox to authenticate itself to MIDCOM agents. When authentication fails, the middlebox MUST not process signaling requests received from the agent that failed authentication. == 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 adapting MIDCOM protocol, the NAT and firewall devices will be able to support newer applications they have not been able to support thus far. MIDCOM protocol does not and MUST not, in anyway, change the fundamental characteristic of NAT and firewall functions in 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. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IETF-STD' is defined on line 766, but no explicit reference was found in the text == Unused Reference: 'SIP' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'RTSP' is defined on line 776, but no explicit reference was found in the text == Unused Reference: 'FTP' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'APPL-ID' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'RFC 1918' is defined on line 798, but no explicit reference was found in the text == Unused Reference: 'RFC 1700' is defined on line 802, 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 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 3027 (ref. 'NAT-COMP') ** Obsolete normative reference: RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) ** 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) Summary: 16 errors (**), 0 flaws (~~), 13 warnings (==), 2 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 August 21, 2001 J. Kuthan 5 GMD Fokus 6 J. Rosenberg 7 Dynamicsoft 8 February, 2001 10 Middlebox Communication Architecture and framework 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet- Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 There are a variety of intermediate devices in the Internet today 37 that require application intelligence for their operation. Many 38 of the applications in use are complex and the datagrams 39 pertaining to these applications cannot be identified by merely 40 examining packet headers. Firewalls and Network Address 41 Translators are typical examples of devices requiring application 42 knowledge. Real-time streaming Voice-over-IP applications such as 43 SIP and H.323 and peer-to-peer applications such as Napster 44 are examples of complex applications. The document specifies an 45 architecture and framework in which trusted third parties can be 46 delegated to assist the intermediate devices with application 47 level intelligence to perform their operation. Doing this will 48 allow the intermediate devices to continue to provide the 49 services, while keeping the devices application agnostic. 51 1. Introduction 53 There are a variety of intermediate devices in the Internet today 54 that require application intelligence for their operation. Many of 55 these devices enforce application specific policy based functions 56 such as packet filtering, differentiated Quality of Service, 57 tunneling, Intrusion detection, security and so forth. Network 58 Address Translators, on the other hand, provide routing 59 transparency across address realms (within IPv4 routing network or 60 across V4 and V6 routing realms). Application Level gateways 61 (ALGs) are used in conjunction with NAT function to provide 62 end-to-end transparency for applications. There may be other 63 types of devices requiring application intelligence for their 64 operation. A middlebox is an intermediate device requiring 65 application intelligence to implement one or more of the 66 functions described. The discussion scope of this document is 67 however limited to middleboxes implementing Firewall and NAT 68 functions only. 70 Tight coupling of application intelligence with intermediate 71 devices makes maintenance of intermediate devices hard with 72 the advent of new applications. Built-in application awareness 73 typically requires updates of operating systems with new 74 applications or newer versions of existing applications. 75 Operators requiring support for newer applications will not be 76 able to use third party software/hardware specific to the 77 application and are at the mercy of their intermediate device 78 vendor to make the necessary upgrade. Further, embedding 79 intelligence for a large number of application protocols within 80 the same device increases complexity of the device and the 81 device is likely to be error prone and degrade in performance. 83 This document describes a framework in which middlebox 84 application intelligence can be moved from intermediate devices 85 into external MIDCOM agents. These MIDCOM agents assist 86 middlebox devices through a generic application-independent 87 middlebox communication (MIDCOM) protocol (yet to be devised). 88 The communication between a MIDCOM agent and a middlebox will 89 be transparent to the end hosts that part take in the 90 application, unless one of the end hosts assumes the role of 91 an external agent. Discovery of middleboxes in the path of an 92 application instance is out of the scope of this document. 94 This document describes the framework in which middlebox 95 communication takes place and the various elements that 96 constitute the framework. Section 2 describes the terms used in 97 the document. Section 3 defines the architectural framework of 98 a middlebox for communication with MIDCOM agents. The remaining 99 sections cover the components of the framework and operational 100 considerations. Section 4 illustrates the various types of 101 MIDCOM agents. Section 5 considers the role of Policy server 102 and its function with regard to MIDCOM agent authorization. 103 Section 6 addresses operational considerations in deploying a 104 protocol adhering to the framework described here. Section 7 is 105 an applicability statement identifying the location of 106 middleboxes, which are the targets of the MIDCOM protocol. 107 Section 8 identifies security considerations for the middlebox 108 in view of the MIDCOM interface. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 114 this document are to be interpreted as described in RFC 2119. 115 Below are the definitions for the terms used throughout the 116 document. 118 2.1. MiddleBox 120 Middlebox is a network intermediate device that requires application 121 specific intelligence for its operation. Intermediate Devices 122 implementing policy based packet filtering, intrusion detection, 123 load balancing, tunneling, IPsec security and Network Address 124 Translation (NAT) functions are all examples of a middlebox device. 125 A middlebox may implement one or more of these functions. 127 2.2. Firewall 129 Firewall is a policy based packet filtering Middlebox, typically 130 used for restricting access to/from specific devices and 131 applications. The policies are often termed Access Control 132 Lists (ACLs). 134 Firewall can perform its function as a stateless device to identify 135 single session applications based on IANA defined well-known ports 136 such as telnet, DNS, HTTP and rlogin, by merely examining the IP 137 (IPv4 or IPv6) and transport headers of the datagrams traversing 138 the device. However, bundled session applications such as FTP, H.323, 139 SIP and RTSP, use a control connection to exchange address and port 140 parameters to establish data sessions and session orientations. 142 Without application specific knowledge of the payload, firewall 143 cannot know the inter-dependency of the bundled sessions and would 144 treat each session as unrelated to one another and may not 145 permit sessions that might need to be permitted. 147 2.3. NAT 149 Network Address Translation is a method by which IP addresses are 150 mapped from one address realm to another, providing transparent 151 routing to end hosts. This is achieved by modifying end node 152 addresses en-route and maintaining state for these updates so 153 that datagrams pertaining to a session are forwarded to the right 154 end-node in either realm. Refer [NAT-TERM] for the various types 155 of NAT devices in use. 157 NAT device alone cannot provide the necessary application/protocol 158 transparency in all cases and seeks the assistance of Application 159 Level Gateways (ALGs) where possible, to provide application level 160 transparency. [NAT-COMP] identifies the protocols and applications 161 that break with NAT enroute. 163 The term NAT in this document is very similar to the IPv4 NAT 164 described in [NAT-TERM], but is extended beyond IPv4 networks 165 to include the IPv4-v6 NAT-PT described in [NAT-PT]. While the 166 IPv4 NAT [NAT-TERM] translates one IPv4 address into another IPv4 167 address to provide routing between private V4 and external V4 168 address realms, IPv4-v6 NAT-PT [NAT-PT] translates an IPv4 address 169 into an IPv6 address and vice versa to provide routing between a 170 V6 address realm and an external V4 address realm. 172 Unless specified otherwise, NAT in this document is a middle box 173 referring to both IPv4 NAT as well as IPv4-v6 NAT-PT devices. 175 2.4. Proxy 177 A proxy is an intermediate relay agent between clients and servers 178 of an application, relaying application messages between the two. 179 Proxies use a special protocol to communicate with proxy clients and 180 relay client data to servers and vice versa. A Proxy terminates 181 sessions with both the client and the server, acting as server to 182 the end-host client and as client to the end-host server. 184 Applications such as FTP, H.323, SIP and RTSP use a control 185 connection to establish data sessions. These control and data 186 sessions can take divergent paths. While a proxy can intercept both 187 the control and data connections, it is possible for it to intercept 188 only the control connection. This is often the case with real-time 189 streaming applications such as H.323, SIP and RTSP. 191 2.5. ALG 193 Application Level Gateways (ALGs) are agents that possess the 194 application specific intelligence and knowledge of an associated 195 middlebox function. An ALG examines application traffic in transit 196 and assists middlebox in carrying out its function. 198 An ALG may be co-resident with a middlebox or reside externally, 199 communicating through a middlebox communication protocol. It 200 interacts with a middlebox to set up state, access control 201 filters, use middlebox state information, modify application 202 specific payload or perform whatever else is necessary to enable 203 the application to run through the middlebox. 205 ALGs are different from proxies, in that, ALGs are transparent to 206 end hosts, unlike the proxies. Proxies terminate sessions with 207 both end-hosts. ALGs, on the other hand, do not terminate session 208 with either end-host. Instead, proxies examine and optionally 209 modify application payload content to facilitate the flow of 210 application traffic through a middlebox. The objective of 211 an ALG is to assist middleboxes in carrying out their function. 212 Whereas, the objective of a proxy is to act as a relay agent 213 between application clients and servers. 215 ALGs are similar to Proxies, in that, both ALGs and proxies 216 facilitate Application specific communication between clients 217 and servers. 219 2.6 End Hosts 221 End hosts are entities that are party to a networked application 222 instance. End hosts referred in this document are specifically 223 those terminating Real-time streaming Voice-over-IP 224 applications such as SIP and H.323 and peer-to-peer applications 225 such as Napster. End-hosts referred in the document are also 226 assumed to be traversing a middlebox device. 228 2.7. MIDCOM Agents 230 MIDCOM agents are entities performing ALG function external to a 231 middlebox. MIDCOM agents may be located either In-Path or 232 Out-of-path of an application instance. 234 In-Path MIDCOM agents are those that are naturally within the 235 message path of the application they are associated with. This may 236 be an application proxy or in the extreme case, one of the 237 end-nodes, that is party to the application. Out-of-Path MIDCOM 238 agents are entities that are not necessarily in the path of 239 application message flows. 241 2.8. Policy Server 243 Policy Server is a management entity that interfaces with a 244 middlebox to enforce policies regarding authorization of MIDCOM 245 agents to access and influence middlebox operation. A MIDCOM agent 246 may be pre-configured on the middlebox as a trusted entity, with 247 or without security credentials. In the case where a MIDCOM agent 248 is not pre-configured, the middlebox will consult Policy Server 249 Out-of-band for validating the authorization to accept requests 250 from the agent. A policy server might add or delete MIDCOM agents 251 on a middlebox. 253 The protocol facilitating the communication between a middlebox and 254 Policy Server need not be MIDCOM protocol 256 2.9. Middlebox Communication (MIDCOM) protocol 258 The protocol used by MIDCOM agents to interface with the middlebox 259 and influence its operation. This is a protocol yet to be devised. 261 3.0 Architectural framework for Middlebox devices 263 A middlebox may implement one or more of the middlebox functions 264 selectively on multiple interfaces of the device. There can be a 265 variety of MIDCOM agents interfacing with the middlebox to 266 communicate with one or more of the middlebox functions on an 267 interface. As such, the communication protocol MUST allow for 268 selective communication between a specific MIDCOM agent and 269 a middlebox function on the interface. The following diagram 270 identifies a possible layering of the functions in a middlebox 271 and a list of MIDCOM agents that might interact with it. 273 +---------+ +----------+ +----------+ 274 | In-Path | | In-Path | | Out-Of- | 275 | Proxy | | Appl. GW | | Path ALG | +--------+ 276 +---------+ +----------+ +----------+ | Policy | 277 ^ ^ | +---| Server | 278 | | | / +--------+ 279 | | | /\/ 280 +-----------+ | | | / +-----------+ 281 | End hosts |<--+ | | | / +-->| End hosts | 282 +-----------+ | | | | | | +-----------+ 283 | | | | | | 284 v v v v v v 285 +-------------------------------------------+ 286 | Middlebox Communication Protocol (MIDCOM) | 287 +----------+--------+-----------+-----------+ 288 Middlebox | | | | | 289 Functions | Firewall | NAT | DIffServ- | Intrusion | 290 | | | QOS | Detection | 291 +----------+--------+-----------+-----------+ 292 Middlebox | ACLs, Sessions, BINDs, AddressMaps and | 293 Managed | other Middlebox function attributes | 294 Resources +-------------------------------------------+ 296 figure 1. MIDCOM agents interfacing with Middlebox devices 298 Resources such as a Session-Descriptor may be shared across 299 middlebox functions. A Session-Descriptor may uniquely identify 300 a session denoted by the tuple of (SessionDirection, 301 SourceAddress, DestinationAddress, Protocol, SourcePort, 302 DestinationPort). An aggregated Session-Descriptor, on the other 303 hand, may have one of the tuple elements denoted by a regular 304 expression (ex: Any source port). The attributes associated 305 with a Session-Descriptor may be specific to the individual 306 middlebox function. As Session-Descriptors are shared across 307 middlebox functions, a Session-Descriptor may be created by a 308 function, and terminated by a different function. For example, a 309 session-descriptor may be created by the firewall function, but 310 terminated by the NAT function, when a session timer expires. 312 A middlebox may also have function specific resources such as 313 Address maps and Address binds to enforce NAT function and Access 314 Control Lists (ACLs) to enforce firewall function. Policies 315 governing a function (such as NAT or firewall) may be based on an 316 application which may not lend itself easy to recognize. 317 Application specific agents (co-resident on the same device or 318 external to the device) would be able to examine the IP datagrams 319 and help identify the application the datagram belongs to. The 320 ALG may also be able to assist the middlebox function in 321 performing functions unique to the application and the middlebox 322 function. For example, an ALG assisting NAT might perform payload 323 translations, in addition to identifying the sessions specific to 324 the application. 326 A few of the middle-box devices deployed are stateless. There are 327 many that are stateful and maintain per-connection state in the 328 system. As such, the MIDCOM protocol must not assume or require 329 that the middlebox to be one way or another and must work with 330 both stateful and stateless devices. 332 4.0. MIDCOM Agents 334 MIDCOM agents are nodes external to a middlebox, possessing 335 a combination of application specific intelligence and knowledge 336 of middlebox function so as to assist middleboxes to perform their 337 function. A MIDCOM agent may communicate with one or more 338 middleboxes. Discovery of the middleboxes a MIDCOM agent 339 communicates with is outside the scope of this document. The focus 340 of the document is the framework in which a MIDCOM agent 341 communicates with a middlebox using MIDCOM protocol, which is 342 yet to be devised. 344 We will examine two types of MIDCOM agents in the following 345 sub-sections. 347 4.1. In-path MIDCOM agents 349 In-Path MIDCOM agents are entities that have a native role in the 350 path of the application traversal (with prior knowledge to one of 351 the application end-hosts), independent of their MIDCOM function. 352 Bundled session applications such as H.323, SIP and RTSP which 353 have separate control and data sessions may have their 354 sessions take divergent paths. In those scenarios, In-Path MIDCOM 355 agents are those that find themselves in the control path. 356 In majority of cases, a middlebox will likely require the 357 assistance of a single agent for an application in the control 358 path alone. However, it is possible that a middlebox function 359 might require the intervention of more than one MIDCOM 360 agent for the same application, one for each sub-session of the 361 application. 363 Application Proxies are a good choice for In-Path MIDCOM agents 364 as proxies, by definition, are in the path of an application 365 between a client and server. Proxies can be interjecting both 366 the control and data connections. For example, FTP control and 367 Data sessions are interjected by an FTP proxy server. However, 368 proxies may also be interjecting just the control connection 369 and not the data connections, as is the case with real-time 370 streaming applications such as H.323, SIP and RTSP. Note, 371 applications may not always traverse a proxy and some applications 372 may not have proxy servers available. 374 4.1.1. In-Path MIDCOM agent illustration 376 SIP proxies and H.323 gatekeepers may be used as MIDCOM agents 377 to control middleboxes implementing firewall and NAT functions. 378 The advantage of using these as opposed to inventing a brand 379 new agent is that the in-path boxes already possess the 380 application intelligence. You will need to merely enable them 381 to communicate using MIDCOM protocol to be effective MIDCOM 382 agents. Figure 2 below illustrates a scenario where the in-path 383 MIDCOM agents interface with the middlebox. Let us say, the 384 policy Server has pre-configured the in-path proxies as trusted 385 MIDCOM agents on the middlebox and the packet filter 386 implements 'default-deny' packet filtering policy. Proxies use 387 their application-awareness knowledge to control the firewall 388 function and selectively permit a certain number of voice stream 389 sessions dynamically using middlebox communication protocol. In 390 addition, the in-path agents may also enforce 391 application-specific choices locally, such as dropping messages 392 infected with known viruses, or lacking user authentication. 394 In the illustration below in figure 2, the MIDCOM agents and the 395 middlebox policy server are shown inside the enterprise boundary. 396 The intent however is not to imply that these entities should 397 reside within the enterprise boundary alone. There are no 398 topological restriction to where these entities can be present, 399 so long as the level of trust relationship with middlebox 400 remains the same. 402 +-----------+ 403 | Middlebox | 404 | Policy | 405 | Server |~~~~~~~~~~~~| 406 +-----------+ \ 407 \ 408 +---------+ SIP \ 409 | SIP |_____________ \ 410 ________| Proxy | \ \ Middlebox 411 / +---------+.. +----+-----+-------+ 412 | : MIDCOM | M | | |__ 413 | RSTP +----------+ :...........| I | | |__ 414 SIP | ____| RSTP |..............| D |FIRE-| |__ 415 | / | Proxy |______________| C | WALL| | 416 | | +----------+ | O | | | 417 | | FTP +---------+.............| M | | | 418 | | _____|FTP Proxy|_____________| | | | 419 | | / +---------+ | La| | | 420 | | | -----| ye| | |-- 421 +-----------+ /-----| r | | |-- 422 +-----------+| Data streams // +----+-----+-------+ 423 +-----------+||----------->----// | 424 |end-hosts ||------------<----- . 425 +-----------+ (RTP, ftp-data, etc.) | 426 . Outside the 427 Within an Enterprise | Enterprise 429 Legend: ---- Application data path datagrams 430 ____ Application control path datagrams 431 .... Middlebox Communication Protocol (MIDCOM) 432 ~~~~ MIDCOM Policy Server Interface 433 | 434 . Enterprise Boundary 435 | 437 Figure 2: In-Path MIDCOM Agents for Middlebox Communication 439 4.1.2. Endhosts as In-Path MIDCOM agents 441 End-hosts are another kind of In-Path MIDCOM agents. Unlike 442 Proxies, End-hosts are direct party to the application and 443 will possess all the end-to-end application intelligence there 444 is to it. End-hosts terminate both the control and data paths 445 of an application. Unlike other MIDCOM agents, end-host is 446 also able to process secure datagrams. However, the problem 447 would be one of scalability - upgrading all the end-hosts 448 running a specific application. 450 4.2. Out-of-Path MIDCOM agents 452 Out-of-Path MIDCOM agents are entities that are not necessarily 453 within the path of application traversal. Out-Of-Path Agents 454 have a role in the application traversal, only by virtue of 455 their MIDCOM function - No native role otherwise. It would be 456 safe to assume that Out-of-Path MIDCOM agents are not in the path 457 of application traversal. Out-of-Path agents have a few 458 benefits. Out-of-Path agents can be implemented in a system, 459 independent of any pre-existing application-aware entity. Unlike 460 In-path agents, there are no topological restrictions to where 461 the agents can be located. Further, multiple application 462 specific agents can be grouped together on the same device. 464 However, Middleboxes seeking the assistance of Out-of-Path MIDCOM 465 agents MUST explicitly redirect application specific datagrams to 466 the agents. In the case of Bundled session applications, if agent 467 assistance is needed for the control path alone, the middlebox 468 will need to redirect only the control path packets to the agent. 470 5.0. Policy Server functions 472 A policy Server interfaces with a middle-box to configure and 473 enforce MIDCOM agent authorization. For example, a policy server 474 has the ability to add or delete MIDCOM agents on a middlebox 475 and to notify a middlebox about the status and security 476 requirements to allow accessibility to MIDCOM agents. 478 The primary objective of a policy server is to ensure that the 479 security and integrity of a middlebox is not jeopardized. 480 Specifically, the policy server should associate a trust level 481 with each node attempting to connect to a middlebox and provide 482 the security guidelines. Some hosts are less secure than others. 483 The policy server must determine trust guidelines for controlling 484 middleboxes according to the level of (presumed) security of the 485 host making the request. The policy server must also determine 486 guidelines to allow end hosts to communicate with the middle-box. 488 5.1. Authentication, Integrity and Confidentiality 490 Host authenticity and individual message authentication are two 491 distinct types of authentications to consider. Host 492 authentication refers to credentials required of a MIDCOM agent 493 to authenticate itself to the middlebox and optionally that of 494 the middlebox to authenticate itself to MIDCOM agents. When 495 authentication fails, the middlebox MUST not process signaling 496 requests received from the agent that failed authentication. 498 To protect MIDCOM messages from being tampered with, Individual 499 message authentication may be used [IPsec-AH] in addition to 500 host authentication. Further, message confidentiality may also 501 be administered by employing IPsec ESP protocol [IPsec-ESP] 502 for the MIDCOM messages to/from a middlebox. Alternately, TLS 503 based security may be employed instead of IPSec security. 504 Simple Source-address based security is the least form of 505 security and should be permitted only to the most trusted 506 hosts. 508 Clearly, the middlebox must be able to perform host level 509 authentication, and be able to authenticate individual messages 510 (using IPsec or TLS based security). 512 5.2. Registration and deregistration with a middlebox 514 Prior to administering a middlebox, a registration process MUST 515 take place as part of the MIDCOM protocol. The MIDCOM agent 516 SHOULD initiate the registration process and it is up to the 517 middlebox to accept or reject. 519 MIDCOM agents, their trust level and accessibility may be 520 pre-registered with the middlebox while provisioning the 521 middlebox function. Either the agent or the middlebox can 522 choose to initiate a connection prior to any data traffic. 523 Alternately, either party (middlebox or the MIDCOM agent) may 524 choose to initiate a connection only upon noticing the 525 application specific traffic. 527 Clearly, middlebox communication adds a new dimension to the way 528 middlebox functions are used to being provisioned. In order for 529 the middlebox to initiate connection to MIDCOM agents, 530 middlebox function provisioning must be altered to reflect the 531 optional ALG presence. For example, a revised ACL tuple for a 532 firewall may be represented as follows. 534 (, , , 535 , , , ) 537 Agent accessibility information must also be provisioned. For a 538 MIDCOM agent, accessibility information includes the IP address, 539 trust level, host authentication profile and message 540 authentication profile. 542 Techniques described above are necessary for the pre-registration 543 of MIDCOM agents with the middlebox. However, it is possible 544 to retain the provisioning on middlebox unchanged, by requiring 545 MIDCOM agents to initiate the connection to middlebox. When 546 Middlebox notices an incoming midcom connection, the middlebox 547 will consult its Policy Server for authenticity, authorization 548 and trust guidelines for the connection. 550 At the end of the MIDCOM session, it SHOULD be possible for 551 either the middlebox or the MIDCOM agent to deregister themselves. 552 Deregistration indicates the termination of MIDCOM session and 553 may be prompted by a successful termination or failure of some 554 sort. 556 6.0. Operational considerations 558 6.1. Multiple MIDCOM connections between agents and middlebox 560 A middlebox cannot be assumed to be a simple device 561 implementing just one middlebox function and no more than a 562 couple of interfaces. Middleboxes often combine multiple 563 intermediate functions into the same device and have the 564 ability to provision individual interfaces of the same device 565 with different sets of functions and varied provisioning for 566 the same function across the interfaces. 568 As such, a MIDCOM agent ought to be able to have a single 569 MIDCOM connection with a middlebox and use the MIDCOM layer 570 on the middlebox to demultiplex to different middlebox 571 functions on the same middlebox interface. Likewise, a 572 middlebox ought to be able to connect to multiple MIDCOM 573 agents, as dictated by the policy server. 575 6.2. Asynchronous notification to MIDCOM agents 577 Asynchronous notification by the middlebox to a MIDCOM agent 578 can be useful for events such as Session creation, Session 579 termination, MIDCOM protocol failure, Middlebox function 580 failure or any other significant event. Independently, ICMP 581 error codes can also be useful to notify transport layer 582 failures to the agents. 584 In addition, periodic notification of statistics update would 585 also be a useful function that would be beneficial to 586 certain types of agents. 588 6.3. Packet redirection 590 Middleboxes must have the ability to redirect packets to MIDCOM 591 agents not in-path. The agent in turn would perform the necessary 592 processing (specific to the application and middlebox function) 593 and forward packet to the actual destination in the 594 first-in-first-out (FIFO) order. Packet forwarding by the 595 agent might necessitate the packet to traverse the middlebox for 596 the second time. The middlebox should simply forward the packet 597 the second time around without redirecting to the agent once 598 again. Failing this, the packet would simply be recycling between 599 the two entities. In order to avoid packet recycling between 600 the agent and the middlebox, one might consider adapting tunneling 601 approach for packet redirection between the agent and the middlebox. 603 6.4. Middlebox variations 605 As stated earlier, a middlebox could be implementing a variety of 606 functions (ex; NAT and firewall) in the same box. Single or multiple 607 agents may be deployed to offer application intelligence to the 608 middlebox functions. However, the functions are assumed to be 609 independent and the sequence in which these function operations 610 may be performed on datagrams is not within the scope of this 611 document. 613 6.5. Signaling and Data traffic 615 A large class of applications we are trying to solve with MIDCOM 616 protocol is focused around applications that have a combination 617 of one or more signaling and data traffic. The signaling 618 may be done out-of-band using a dedicated stand-alone session 619 or may be done in-band with data session. Alternately, signaling 620 may also be done as a combination of both stand-alone and 621 in-band sessions. 623 SIP is an example of an application based on distinct signaling 624 and data sessions. SIP signaling session is used for call setup 625 between a caller and a callee. MIDCOM agent may be required to 626 examine/modify SIP payload content to administer the middlebox 627 so as to let the media streams (RTP/RTSP based) through. MIDCOM 628 agent is not required to intervene in the data traffic. 630 Signaling and context specific Header information is sent in-band 631 within the same data stream for applications such as HTTP embedded 632 applications, sun-RPC (embedding a variety of NFS apps), Oracle 633 transactions (embedding oracle SQL+, MS ODBC, Peoplesoft) etc. 635 H.323 is an example of application that sends signaling in both 636 dedicated stand-alone session as well as in conjunction with data. 637 Q.931 traffic traverses middleboxes by virtue of static policy, 638 no MIDCOM control needed. Q.931 also negotiates ports for an 639 H.245 TCP stream. A MIDCOM agent is required to examine/modify 640 the contents of the H.245 so that H.245 can traverse it. 642 H.245 traverses the middlebox and also carries Open Logical 643 Channel information for media data. So the MIDCOM agent is once 644 again required to examine/modify the payload content needs to 645 let the media traffic flow. 647 MIDCOM protocol is capable of supporting applications with 648 independent signaling and data sessions as well as 649 applications that have signaling and data communicated over 650 the same session. 652 In the cases where signaling is done on a single stand-alone 653 session, it is desirable to have a MIDCOM agent interpret the 654 signaling stream and program the middlebox (that transits the 655 data stream) so as to let the data traffic through uninterrupted. 657 7. Applicability Statement 659 Middleboxes may be stationed in a number of topologies. However, the 660 signaling framework outlined in this document may be limited to only 661 those middleboxes that are located in a DMZ (De-Militarized Zone) at 662 the edge of an enterprise, connecting to the Internet. Specifically, 663 the assumption is that you have a single middlebox (running NAT or 664 firewall) along the application route. Discovery of middlebox along 665 application route is outside the scope of this document. 666 It is conceivable to have middlebox devices located between 667 departments within the same enterprise or inside service provider's 668 domain and so forth. However, care must be taken to review each 669 individual scenario and determine the applicability on a 670 case-by-case basis. 672 The applicability may also be illustrated as follows. Real-time and 673 streaming applications such as Voice-Over-IP and peer-to-peer 674 applications such as Napster require administering firewall 675 and NAT devices to let their media streams reach hosts inside 676 a private domain. The requirements are in the form of establishing 677 a "pin-hole" to permit a TCP/UDP session (the port parameters of 678 which are dynamically determined) through a firewall or retain an 679 address/port bind in the NAT device to permit connections to a 680 port. These requirements are met by current generation firewall 681 and NAT devices using adhoc methods, such as combining application 682 intelligence with these NAT devices to identify the dynamic session 683 parameters and administer the NAT and firewall devices internally 684 as appropriate. The objective of the MIDCOM protocol is to create 685 a unified, standard way to exercise this functionality, currently 686 existing in an ad-hoc fashion in some of the middlebox devices. 688 By adapting MIDCOM protocol, the NAT and firewall devices will 689 be able to support newer applications they have not been able to 690 support thus far. MIDCOM protocol does not and MUST not, in 691 anyway, change the fundamental characteristic of NAT and firewall 692 functions in the middlebox. 694 Typically, organizations shield a majority of their corporate 695 resources (such as hosts) from visibility to the external network 696 by the use of a De-Militarized Zone (DMZ) at the enterprise edge. 697 Only a portion of these hosts are allowed to be accessed by the 698 external world. The remaining hosts and their names are unique to 699 the enterprise. Hosts visible to the external world and the 700 authoritative name server that maps their names to network 701 addresses are often configured within a DMZ (De-Militarized Zone) 702 in front of a firewall. Hosts and middleboxes within DMZ are 703 referred to as DMZ nodes. 705 Figure 3 below illustrates configuration of an enterprise with a DMZ 706 at its edge. Actual configurations may vary. Internal hosts are 707 accessed only by users inside the enterprise. Middleboxes, located 708 in the DMZ may be accessed by agents inside or outside the 709 enterprise. 711 \ | / 712 +-----------------------+ 713 |Service Provider Router| 714 +-----------------------+ 715 WAN | 716 Stub A .........|\|.... 717 | 718 +---------------+ 719 | NAT Middlebox | 720 +---------------+ 721 | 722 | DMZ - Network 723 ------------------------------------------------------------ 724 | | | | | 725 +--+ +--+ +--+ +--+ +-----------+ 726 |__| |__| |__| |__| | Firewall | 727 /____\ /____\ /____\ /____\ | Middlebox | 728 DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web +-----------+ 729 Server Server etc. | 730 | 731 Internal Hosts (inside the enterprise) | 732 ------------------------------------------------------------ 733 | | | | 734 +--+ +--+ +--+ +--+ 735 |__| |__| |__| |__| 736 /____\ /____\ /____\ /____\ 737 Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server 739 Figure 3: DMZ network configuration of an enterprise. 741 8. Acknowledgements 743 The authors wish to express their thanks and gratitude to the 744 following for their valuable critique, advice and input on an 745 earlier rough version of this document. Abdallah Rayhan, Andrew 746 Molitor, Christian Huitema, Joon Maeng, Jon Peterson, Mike Fisk, 747 Matt Holdrege, Paul Sijben, Philip Mart, Scott Brim and Richard 748 Swale. 750 9. Security Considerations 752 MIDCOM protocol framework has significant security considerations 753 to the operation of the middlebox. Section 5 is devoted to 754 addressing the security vulnerabilities of the middlebox from 755 MIDCOM agents. There is also a security vulnerability due to 756 shared resources between the middlebox functions co-resident on the 757 same device. It is possible that a middlebox function may be 758 abruptly disrupted due to malicious manipulation of the resource by 759 an agent purporting to offer ALG service for a different middlebox 760 function. Careful consideration must be given in the protocol 761 design to ensure that agents for one function do not abruptly step 762 over the resources impacting a different function. 764 REFERENCES 766 [IETF-STD] Bradner, S., " The Internet Standards Process -- 767 Revision 3", RFC 1602, IETF, October 1996. 769 [SIP] Handley, M., H. Schulzrinne, E. Schooler, and 770 J. Rosenberg, "SIP: Session Initiation Protocol", 771 RFC 2543, IETF, March 1999. 773 [H.323] ITU-T Recommendation H.323. "Packet-based Multimedia 774 Communications Systems," 1998. 776 [RTSP] Schulzrinne, H., A. Rao, R. Lanphier: "Real Time 777 Streaming Protocol", RFC 2326, IETF, April 1998. 779 [FTP] J. Postel, J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", 780 RFC 959 782 [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address 783 Translator (NAT) Terminology and Considerations", 784 RFC 2663, August 1999. 786 [NAT-COMP] Holdrege, M. and Srisuresh, P., "Protocol Complications 787 with the IP Network Address Translator", RFC 3027, 788 January 2001. 790 [NAT-PT] Tsirtsis, G. and Srisuresh, P., "Network Address 791 Translation - Protocol Translation (NAT-PT)", 792 RFC 2766, February 2000. 794 [APPL-ID] Bernet, Y. and Pabbati, R., "Application and Sub 795 Application Identity Policy Element for Use with 796 RSVP", RFC 2872, June 2000. 798 [RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., 799 de Groot, G. and E. Lear, "Address Allocation for 800 Private Internets", BCP 5, RFC 1918, February 1996. 802 [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", 803 RFC 1700 805 [IPsec-AH] Kent, S., and R. Atkinson, "IP Authentication 806 Header", RFC 2402, November 1998. 808 [IPsec-ESP] Kent, S., and R. Atkinson, "IP Encapsulating 809 Security Payload (ESP)", RFC 2406, November 1998. 811 Authors' Addresses 813 Pyda Srisuresh 814 Jasmine Networks 815 3061 Zanker Road, Suite B 816 San Jose, CA 95134 817 U.S.A. 818 Voice: (408) 895-5032 819 EMail: srisuresh@yahoo.com 821 Jiri Kuthan 822 GMD Fokus 823 Kaiserin-Augusta-Allee 31 824 D-10589 Berlin, Germany 825 E-mail: kuthan@fokus.gmd.de 827 Jonathan Rosenberg 828 dynamicsoft 829 200 Executive Drive 830 Suite 120 831 West Orange, NJ 07052 832 U.S.A. 833 email: jdrosen@dynamicsoft.com