Requirements for Firewall Configuration Protocol

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

2. 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. Content • Pinhole creation requirements • Pinhole deletion requirements • Packet filters requirements • State Update requirements • Transport protocol preferences • Firewall feature requirements • Other requirements

4. 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. 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. 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. 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. 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. 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. Client Firewall

10. 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. Questions • Can the NAT/FW NSLP support or be extended to support these requirements?