Transcript MIDCOM-1

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