1. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 1 Arguments creating a Firewalls Issues Group within GGF Ralph Niederberger Research Center Jülich Jülich, Germany r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF Presentation for GGF13, Seoul, Korea, March, 13th 2005

2. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 2 Grid projects and its implications Grid-Projects with external partners often lead to communication relationships between external and internal computer systems requiring special configurations at firewall systems This implies –Allowing access for communication sessions (ports) –Allowing access to single systems or sub networks in general –Allowing access via physical or logical links as fiber, wavelength, sub wavelength This results in –administrative overhead –wildcard access rights (port not known, so give access to whole system) –softening of security policies (weaker policies, no security policies anymore) –general decreasing security level to that of the partner installation –security vulnerability because of open ports for long time periods

3. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 3 Todays firewalls –are limited to 1 Gb/s throughput often, some already allow 10 Gb/s –Often load balancing of multiple firewalls is done based on IP or MAC-address balancing, i.e one stream will be executed by one firewall giving real balancing only with multiple communication streams. Grid applications with huge bandwidth demands do not have any advantage of these firewalls. –Some firewall clusters allow round robbin mechanisms, but are limited to lower speeds because of the extreme overhead needed for status information updates between the different firewall components –Only a small amount of firewall systems is able to handle applications with dynamically assigned ports –Some implementations are known for applications like ftp, h.323, sip –But no general solution is available

4. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 4 Projects today –Every installation has its own firewall –Project networks are placed in a demilitarized zone mostly –Every computer system used in the project has to be secured –Bad or wrong configured systems lead to security vulnerabilities –Supercomputers or special systems are connected via dedicated networks –Assuming “Net of Trust”, i.e. users at these systems will be trusted leading to insider security problem –Compromise of these systems leads to increased security problems –Access lists for ports, systems, networks have to be configured manually which implies additional overhead

5. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 5 Projects at Research Center Jülich and firewall implications Research Center Jülich involved in many national & international projects DEISA - deploying and operate a persistent, production quality, distributed supercomputing environment, http://www.deisa.orghttp://www.deisa.org  currently using dedicated network (only router ACLs) VIOLA - set up an optical test bed with fibers connecting the project partners in Germany, used to test advanced network equipment and architectures, to develop software for user-driven dynamical provisioning of bandwidth and Quality of Service, and to develop and enhance advanced Grid- and distributed visualisation applications and Grid-middleware. http://www.viola-testbed.de http://www.viola-testbed.de  currently using “net of trust model” (cluster machines in DMZ separated from local installation networks) Other grid projects at Research Center Jülich UNICORE, UNICORE Plus, EUROGRID, GRIP, OpenMolDRID, PAB, GRIDSTART, GRIDWELTEN, UniGrids, NextGrid, CoreGRID, GRANDE, GARDEN  see http://www.fz-juelich.de/zam/grid/projekte

6. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 6 Some new FW activities launched –D-Grid (German project to be funded by BMBF) work package: AP 7 - Design and deployment of firewall concepts within grid environments (Performance and dynamic configuration) http://www.d-grid.de –EGEE (European Project funded by EU) Service Activity 1, http://egee-sa1.web.cern.ch/egee%2Dsa1/Security.htm –MIDCOM (IETF): http://www.iptel.org/fcp/ & http://www.iptel.org/info/players/ietf/firewall/midcom/ –OPSEC (CheckPoint): http://www.opsec.com/ –ACDC-Grid Firewall „Advanced Computational Data Center Dynamic Firewall (ACDC Dyna- Fire) Development“ http://www.ccr.buffalo.edu/grid/content/research –Many other activities are on the way

7. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 7 Firewall definition and short history Definition of the term Firewall A firewall is the implementation of a security policy of an institution concerning traffic exchange between different security domains. It is no black box or single hardware It can be much more. It is all the rules you specify, to become safe. It is the way you check the compliance with these rules. It is the whole bunch of software and hardware you use to implement this.

8. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 8 Short history of firewalls –TIS (Trusted Information Systems) firewall toolkit released in 1995 (application firewall) –later on firewalls as packet screens, looking into each packet –firewall als statefull inspection engine –knowing about TCP sessions (streams) –defining UDP Streams as „sessions“ (Timeout managed) –extension to „application aware protocols“ -> http, ftp,..., –allowing to accept streams with unknown ports (dynamic access) –allowing to check, if stream really a http-stream or e.g. a tunneled music download –tendencies are going back to application level firewalls

9. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 9 Always growing bandwidth of networks requires a reconsidering of techniques Checking every single packet not possible anymore Firewalls cannot be faster as normal network interfaces, so new ideas have to be found Instead of single packets streams could be checked Many connections will be allowed without checking the content of the connection. The connection will be allowed because of the fact that an instance, the destination system, checked the authorization. Examples are: ssh traffic into local networks, IPSec connections between local and remote machines There are no high performance firewalls to secure fiber links with 32, 64, 128 wavelength with 10 Gb/s throughput each? New firewall demands

10. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 10 New ideas Why should we not allow the switching of paths, virtual paths, real paths, fiberlinks, wavelengths, … We do not know for why an IPsec connection has been initiated. –It could be a host-to-host link –It could be a net-to-host link –It could be a net-to-net link –It could be an unwanted tunneled connection violating the security policy Authorization checking will be performed by the application: –Trusting the IPsec connection –Trust in UID/Password mapping / checking –Trust in checking of certificates

11. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 11 What do we need We need a authorization protocol that checks authorization of inquiries and instructs an entity –to allow or deny traffic, –to switch (switch off) light paths and We need the implementation of this authorization protocol –into a firewall concept (policies, software and hardware) To allow network elements to switch paths after being instructed by an authorized instance

12. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 12 To become precise An authorization protocol has to be defined and standardized, which checks the authorization of a client (e.g. the grid application, the user, …) if it has the right permission to request the use or creation of a communication path. If the authorization has been granted the router, cross connect, … has to be informed / instructed to create the requested connection entity

13. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 13 The firewall issue A firewall can be divided into –Authorization check instance and –Routing / switching instance The authorization check instance corresponds to the access rules, statically authourized and configured by the firewall administrator The forwarding instance is the executing part of the firewall, the router part, which routes the packets to the destination after checks have been done, or it is the cross connect which switches paths and switches them off after transaction

14. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 14 Abstraction The authorization check instance is a server which checks authorization –may the application use the port –may the system A communicate with system B –may the protocol (e.g. ssh to inside) be used without checking the contents of the connection –May the wavelength be switched from site A to side B The forwarding instance will be the executing instrument, the networking hardware –It’s the firewall in the classical view having checked the access lists authorized (and configured) by the administrator and now forwarding or denying the packet –It’s the router, changing routing tables –It’s the cross connect switching virtual or real optical paths

15. r.niederberger@fz-juelich.de Mar, 8th 2005 Arguments creating a FIG WG within GGF 15 Tasks to be done by FIG –Checking which protocols, procedures, mechanisms are available already –Evaluating, which of these can be used to reach the defined goals –Definition of the new protocols, datastructures and security mechanisms –(Implementing a prototype) Strategic objectives will be to define a standardized authorization mechanism accepted and implemented by firewall vendors into their systems so that grid enabled firewalls will become reality.