* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download MIDCOM-1
Survey
Document related concepts
Wake-on-LAN wikipedia , lookup
Wireless security wikipedia , lookup
Computer security wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Computer network wikipedia , lookup
Network tap wikipedia , lookup
Airborne Networking wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Internet protocol suite wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Deep packet inspection wikipedia , lookup
Quality of service wikipedia , lookup
UniPro protocol stack wikipedia , lookup
Transcript
Middlebox Communication Framework and Requirements Jiri Kuthan Jonathan Rosenberg GMD-Fokus dynamicsoft [email protected] [email protected] December 2000, 49th IETF, MidCom BOF Outline Background transparency loss ALGs embedded in intermediate network devices Suggestion: decomposition of intermediate network devices Driver: co-existence of firewalls, NATs, NAT-PTs with applications using session control protocols Missing piece: protocol between ALGs and intermediate network devices Conclusions 49th IETF Meeting draft-kuthan-midcom-framework-00.txt 2 Background: ALGs Loss of Transparency (RFC2775) ALGs are one of the mechanisms that assist applications in traversing network realms (IPv4, IPv6, NAT, FW, ...) ALGs are embedded maintainability not very good (numerous application protocols, V1, V2, V3, ...) application-awareness is likely to affect performance neither end-2-end nor hop-by-hop security supported Decomposition desired: ALGs stay but not in network devices Case study: firewall/NAT traversal of applications relying on session control 49th IETF Meeting draft-kuthan-midcom-framework-00.txt 3 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 Meeting draft-kuthan-midcom-framework-00.txt 4 Static Filtering Policy is not Enough Filtering 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) The problem: all these policies static; they prohibit dynamic conditions such as sessions established using a session control protocol (SIP, H.323, RTSP) Note: such protocols are not a bug, they are a feature needed by many applications 49th IETF Meeting draft-kuthan-midcom-framework-00.txt 5 Application-awareness to Deal with Dynamic Conditions To make firewalls understand dynamic conditions, they need to understand them -> Application Level Gateways firewalls w/ALGs transparent, i.e. no firewall support in enddevices needed Traditional ALGs are embedded Problems: maintainability not very good (numerous application protocols, V1, V2, V3, ...) application-awareness is likely to affect performance neither end-2-end nor hop-by-hop security supported 49th IETF Meeting draft-kuthan-midcom-framework-00.txt 6 Suggestion: Decomposition We suggest using externalized ALGs accessing the intermediate network devices such as firewalls/NA(P)Ts/NAT-PTs via a generic control protocol Benefits: intermediate network devices need to speak a single control protocol; ALG may be supplied by third parties easily existing application-awareness (e.g., SIP proxies) may be reused (as opposed to duplicating it in network devices) hop-by-hop security works 49th IETF Meeting draft-kuthan-midcom-framework-00.txt 7 Missing Piece Protocol 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) Application-independent Control data: {packet matching expression, pass/drop, packet counter, ...} Extensible (new per-flow state members may be added) Secure Examples: - udp From 193.174.154.10:44444 To 195.113.150.66:55555 Pass - udp From 10.0.0.1:44444 To 195.113.150.66:55555 Modify source_ip=FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 49th IETF Meeting draft-kuthan-midcom-framework-00.txt 8 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 Summary: We have ... problem statement, which is suboptimal deployability of embedded ALGs that help applications to traverse various realms, such as IPv4, IPv6, networks behind NATs, FWs solution, which is control of per-flow states extensibility, which allows to use the same solution for other purposes related to control of flow processing 49th IETF Meeting draft-kuthan-midcom-framework-00.txt 10 Conclusions FCP makes traversal of applications across different realms easier by making ALGs better deployable. Disclaimer: FCP does not fix loss of transparency; it makes it easier to live with and it may help transition to IPv6. Are we going to form a new WG that will deal with this kind of protocol? 49th IETF Meeting draft-kuthan-midcom-framework-00.txt 11 Information Resources Authors Jiri Kuthan, [email protected] Jonathan Rosenberg, [email protected] Mailing list where FCP has been discussed [email protected] To subscribe, send email to [email protected] with “subscribe foglamps” in the body of message Archive: http://www.fokus.gmd.de/glone/ietf/foglamps/ The requirements and framework I-D: draft-kuthan-midcom-framework-00.txt 49th IETF Meeting draft-kuthan-midcom-framework-00.txt 12