Middlebox Communication Framework and Requirements Jiri Kuthan GMD-Fokus Jonathan Rosenberg dynamicsoft December 2000, 49th IETF, MidCom BOF

49th IETF Meetingdraft-kuthan-midcom-framework-00.txt 2 Outline zBackground ytransparency loss yALGs embedded in intermediate network devices zSuggestion: decomposition of intermediate network devices zDriver: co-existence of firewalls, NATs, NAT-PTs with applications using session control protocols zMissing piece: protocol between ALGs and intermediate network devices zConclusions

49th IETF Meetingdraft-kuthan-midcom-framework-00.txt 3 Background: ALGs zLoss of Transparency (RFC2775) zALGs are one of the mechanisms that assist applications in traversing network realms (IPv4, IPv6, NAT, FW,...) zALGs are embedded ymaintainability not very good (numerous application protocols, V1, V2, V3,...) yapplication-awareness is likely to affect performance yneither end-2-end nor hop-by-hop security supported zDecomposition desired: ALGs stay but not in network devices zCase study: firewall/NAT traversal of applications relying on session control

49th IETF Meetingdraft-kuthan-midcom-framework-00.txt 4 Ultimately Secure Firewall Installation Instructions: For best effect install the firewall between the CPU unit and the wall outlet. Place the jaws of the firewall across the power cord, and bear down firmly. Be sure to wear rubber gloves while installing the firewall or assign the task to a junior system manager. If the firewall is installed properly, all the lights on the CPU will turn dark and the fans will grow quiet. This indicates that the system has entered a secure state. For Internet use install the firewall between the demarc of the T1 to the Internet. Place the jaws of the firewall across the T1 line lead, and bear down firmly. When your Internet service provider's network operations center calls to inform you that they have lost connectivity to your site, the firewall is correctly installed. (© Marcus Ranum)

49th IETF Meetingdraft-kuthan-midcom-framework-00.txt 5 Static Filtering Policy is not Enough zFiltering policy in firewalls can be set up anywhere in the range between the ultimate (see previous slide) and completely open firewall (see what Microsoft suggests to enable NetMeeting in networks with firewalls) zThe problem: all these policies static; they prohibit dynamic conditions such as sessions established using a session control protocol (SIP, H.323, RTSP) zNote: such protocols are not a bug, they are a feature needed by many applications

49th IETF Meetingdraft-kuthan-midcom-framework-00.txt 6 Application-awareness to Deal with Dynamic Conditions zTo make firewalls understand dynamic conditions, they need to understand them -> Application Level Gateways yfirewalls w/ALGs transparent, i.e. no firewall support in end- devices needed zTraditional ALGs are embedded zProblems: ymaintainability not very good (numerous application protocols, V1, V2, V3,...) yapplication-awareness is likely to affect performance yneither end-2-end nor hop-by-hop security supported

49th IETF Meetingdraft-kuthan-midcom-framework-00.txt 7 Suggestion: Decomposition zWe suggest using externalized ALGs accessing the intermediate network devices such as firewalls/NA(P)Ts/NAT-PTs via a generic control protocol zBenefits: yintermediate network devices need to speak a single control protocol; ALG may be supplied by third parties easily yexisting application-awareness (e.g., SIP proxies) may be reused (as opposed to duplicating it in network devices) yhop-by-hop security works

49th IETF Meetingdraft-kuthan-midcom-framework-00.txt 8 Missing Piece zProtocol for communicating control data associated with IP/transport-layer data flows or aggregates of them between intermediate packet processing devices and external controllers: Flow State Control Protocol (FCP) zApplication-independent zControl data: {packet matching expression, pass/drop, packet counter,...} zExtensible (new per-flow state members may be added) zSecure zExamples: - udp From :44444 To :55555 Pass - udp From :44444 To :55555 Modify source_ip=FEDC:BA98:7654:3210:FEDC:BA98:7654:3210

A MidCom Network Administrator-Maintained Zone | App. | | Policy | SIP | Server |~~~~~~~~~| SIP +_____________ | ________| Proxy | \ | / | : FCP |_______ | RSTP : | | Per-Flow | | SIP | ____| RSTP | | | State | | | / | Proxy |______________| FCP | Table | |_______ | | | unit | | | | | FTP | | ACL | | | | _____|FTP Proxy|_____________ |_______ | | / | Intermediate | | | | -----| Network | /-----| Device | | data streams // || >----// | |end-devices|| <----- | (RTP, ftp-data, etc.) | Inside | Outside Legend: ---- raw data streams ____ application control protocols.... FCP ~~~~ policy protocol

49th IETF Meetingdraft-kuthan-midcom-framework-00.txt 10 Summary: We have... zproblem statement, which is suboptimal deployability of embedded ALGs that help applications to traverse various realms, such as IPv4, IPv6, networks behind NATs, FWs zsolution, which is control of per-flow states zextensibility, which allows to use the same solution for other purposes related to control of flow processing

49th IETF Meetingdraft-kuthan-midcom-framework-00.txt 11 Conclusions zFCP makes traversal of applications across different realms easier by making ALGs better deployable. zDisclaimer: FCP does not fix loss of transparency; it makes it easier to live with and it may help transition to IPv6. zAre we going to form a new WG that will deal with this kind of protocol?

49th IETF Meetingdraft-kuthan-midcom-framework-00.txt 12 Information Resources zAuthors yJiri Kuthan, yJonathan Rosenberg, zMailing list where FCP has been discussed yTo subscribe, send to with “subscribe foglamps” in the body of message yArchive: zThe requirements and framework I-D: ydraft-kuthan-midcom-framework-00.txt