110 likes | 122 Views
Learn about pinhole creation, packet filters, state updates, transport protocol preferences, and more requirements for 3GPP2 Firewall Configuration Protocol as specified in draft-bajko-nsis-FW-reqs-00.txt.
E N D
Requirements for Firewall Configuration Protocol March 10th, 2005 Gabor Bajko Franck Le Michael Paddon Trevor Plestid Draft-bajko-nsis-FW-reqs-00.txt
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
Content • Pinhole creation requirements • Pinhole deletion requirements • Packet filters requirements • State Update requirements • Transport protocol preferences • Firewall feature requirements • Other requirements
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)
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
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
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
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.
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
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.
Questions • Can the NAT/FW NSLP support or be extended to support these requirements?