1 © NOKIA FILENAMs.PPT/ DATE / NN Requirements for Firewall Configuration Protocol March 10 th, 2005 Gabor Bajko Franck Le Michael Paddon Trevor Plestid Draft-bajko-nsis-FW-reqs-00.txt

2 © NOKIA FILENAMs.PPT/ DATE / NN Introduction 3GPP2 has decided to specify the adoption and utilization of firewalls in their network The need for a protocol allowing clients to configure firewalls has been identified This presentation provides an overview of the requirements that have been identified for the Firewall Configuration Protocol in 3GPP2 Internet draft: draft-bajko-nsis-FW-reqs-00.txt

3 © NOKIA FILENAMs.PPT/ DATE / NN Content Pinhole creation requirements Pinhole deletion requirements Packet filters requirements State Update requirements Transport protocol preferences Firewall feature requirements Other requirements

4 © NOKIA FILENAMs.PPT/ DATE / NN Pinhole creation requirements A client SHOULD be able to create pinholes and specify the characteristics of the pinholes to be installed in the firewalls. A client SHOULD be able to specify pinholes that admit classes of packets, i.e. a single pinhole should permit ranges of values in header fields. A client SHOULD be able to specify pinholes that refer to encapsulated headers (Mobile IP or tunneling) or routing options (Mobile IPv6). The end point SHOULD be able to create pinholes with wildcard for any field (e.g. port number, IP address, etc.) Terminal hosting servers Mobile IPv6 signaling (e.g. Binding Update, CoTI messages)

5 © NOKIA FILENAMs.PPT/ DATE / NN Pinhole deletion requirements A client SHOULD be able to close any or all the pinholes it created with a single protocol instance. A client SHOULD be able to suggest a pinhole timeout. A firewall SHOULD be able to override such suggestions. A client SHOULD be able to refresh all associated pinhole timeouts with a single protocol instance

6 © NOKIA FILENAMs.PPT/ DATE / NN Packet filters requirements The protocol MUST support specifying the action to be taken for packets matching the packet filters. For each packet filter, the protocol MUST be able to indicate whether packets matching the filter should 'PASS' or if the firewall should 'DROP' them. The actions MUST be extendable. These capabilities are useful to Restrict the packets Restrict the services Block overbilling attacks

7 © NOKIA FILENAMs.PPT/ DATE / NN State Update requirements The client SHOULD be able to update the pinholes and/or packet filters installed in the firewall. The client SHOULD be able to update the firewall states by providing: the fields to be updated the values for the fields to be updated This capability is useful e.g. for: MIPv6 RFC 3041

8 © NOKIA FILENAMs.PPT/ DATE / NN Transport protocol preferences The granularity of the rules SHOULD allow an end point to specify the TCP flags, and other transport protocol related information (e.g. the end point should have the ability to specify that it does not want to receive TCP SYN packets.) The protocol MUST be extendable to allow further more complex actions.

9 © NOKIA FILENAMs.PPT/ DATE / NN Firewall features requirements The protocol SHOULD allow the client to retrieve the rules installed in the FW. The protocol SHOULD allow the client to learn the features implemented in the FW and whether those are enabled or disabled. The protocol SHOULD allow the client to configure the Firewall (e.g. enable/disable a feature in the FW). Certain Firewalls implement features to protect nodes, e.g. SYN Relay. These features however, may present issues to e2e communications Knowing in advance the features enabled in the Firewall may help nodes choosing adequate protocols and succeed with end-to-end communication. ClientFirewall

10 © NOKIA FILENAMs.PPT/ DATE / NN Other requirements The protocol SHOULD allow an end point to create, modify or delete several firewall states with one protocol instance. The protocol SHOULD be applicable both for IPv4 and IPv6.

11 © NOKIA FILENAMs.PPT/ DATE / NN Questions Can the NAT/FW NSLP support or be extended to support these requirements?