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?