To configure IP Security, tunnels and filters need to be configured. If a simple tunnel is to be defined where all the traffic uses the tunnel, the filter rules can be automatically generated. If more complex filtering is desired, filter rules can be configured separately.
There are two related but distinct parts of IP Security: tunnels and filters. Tunnels require filters, but filters do not require tunnels.
Filtering is a basic function in which incoming and outgoing packets can be accepted or denied based on a variety of characteristics. This allows a system administrator to configure the host to control the traffic between this host and other hosts. Filtering is done on a variety of packet properties, such as source and destination addresses, IP Version (4 or 6), subnet masks, protocol, port, routing characteristics, fragmentation, interface, and tunnel definition. This filtering is done at the IP layer, so no changes are required to the applications.
Tunnels define a security association between two hosts. These security associations involve specific security parameters that are shared between end points of the tunnel.
The following illustration indicates how a packet comes in the network adapter to the IP stack. From there, the filter module will be called to determine if the packet should be permitted or denied. If a tunnel ID is specified, the packet will be checked against the existing tunnel definitions. If the decapsulation from the tunnel is successful, the packet will be passed to the upper layer protocol. This function will occur in reverse order for outgoing packets. The tunnel relies on a filter rule to associate the packet with a particular tunnel, but the filtering function can occur without passing the packet to the tunnel.
Tunnels are used whenever it is desired to have data authenticated, or authenticated and encrypted. Tunnels are defined by specifying a security association between two hosts (see figure). The security association defines the parameters for the encryption and authentication algorithms and characteristics of the tunnel.
The Security Parameter Index, SPI, and the destination address identify a unique security association. Therefore, these two parameters are required for uniquely specifying a tunnel. Other parameters such as cryptographic algorithm, authentication algorithm, keys, and lifetime can be specified or defaults can be used.
The decision to use IBM or Manual tunnels depends on the tunnel support of the remote end and the type of key management desired. If IBM tunnels are offered, they may be preferable because IBM tunnels provide automatic key refreshment. If the remote end does not support IBM tunnels, or uses one of the algorithms requiring manual tunnels, manual tunnels should be used. Manual tunnels ensure interoperability with a large number of hosts. Because the keys are static and difficult to change and may be cumbersome to update, they are not as secure.
IBM Tunnels may be used between any two AIX machines running AIX Version 4.3, or between an AIX 4.3 host and a host running IBM Secure Network Gateway 2.2 or IBM Firewall 3.1. manual tunnels may be used between a host running AIX Version 4.3 and any other machine running IP Security and having a common set of cryptographic and authentication algorithms. Almost all vendors offer Keyed MD5 with DES, or HMAC MD5 with DES. This is a base subset that works with almost all implementations of IP Security.
When setting up tunnels, the procedure depends on whether you are setting up the first host of the tunnel, or setting up the second host, which must have parameters matching the first host's setup.
When setting up the first host, the keys may be autogenerated, and the algorithms can be defaulted. When setting up the second host, it is best to import the tunnel information from the remote end, if possible.
Another important consideration is determining whether the remote system is behind a firewall. If it is, the setup must include information about the intervening firewall. A firewall can either serve as the endpoint for the tunnel, or it can be configured to allow traffic in tunnel to pass through it. This will depend on the preferred security policy for the site containing the firewall.
For the simplest case, setting up a manual tunnel, it is not necessary to separately configure the filter rules. As long as all traffic goes through the tunnel, the necessary filter rules will be automatically generated. The process of setting up a tunnel is to define the tunnel on one end, import the definition on the other end, and activate the tunnel and filter rules on both ends. Then the tunnel is ready to be used.
Information about the tunnel will be made to match on both sides if it is not explicitly supplied (see figure). For instance, the encryption and authentication algorithms specified for the source will be used for the destination if the destination values are not specified. This makes creating the tunnel much simpler.
You can configure a tunnel using the SMIT fast path ips4_basic (for IP Version 4) or ips6_basic (for IP version 6), or you can use the following procedure.
The following is a sample of the gentun command used to create a tunnel:
gentun -v 4 -t manual -s 5.5.5.19 -d 5.5.5.8 -a HMAC_MD5 -e DES_CBC_8 -N 23567
This will create a tunnel, whose output (using lstun -v 4) will look similar to:
Tunnel ID : 1 IP Version : IP Version 4 Source : 5.5.5.19 Destination : 5.5.5.8 Policy : auth/encr Tunnel Mode : Tunnel Send AH Algo : HMAC_MD5 Send ESP Algo : DES_CBC_8 Receive AH Algo : HMAC_MD5 Receive ESP Algo : DES_CBC_8 Source AH SPI : 300 Source ESP SPI : 300 Dest AH SPI : 23576 Dest ESP SPI : 23576 Tunnel Life Time : 480 Status : Inactive Target : - Target Mask : - Replay : No New Header : Yes Snd ENC-MAC Algo : - Rcv ENC-MAC Algo : -
The tunnel will be activated when the mktun command is used:
mktun -v 4 -t1
The filter rules associated with the tunnel will be automatically generated and output (using lsfilt -v 4) will look similar to:
Rule 4: Rule action : permit Source Address : 5.5.5.19 Source Mask : 255.255.255.255 Destination Address : 5.5.5.8 Destination Mask : 255.255.255.255 Source Routing : yes Protocol : all Source Port : any 0 Destination Port : any 0 Scope : both Direction : outbound Logging control : no Fragment control : all packets Tunnel ID number : 1 Interface : all Auto-Generated : yes Rule 5: Rule action : permit Source Address : 5.5.5.8 Source Mask : 255.255.255.255 Destination Address : 5.5.5.19 Destination Mask : 255.255.255.255 Source Routing : yes Protocol : all Source Port : any 0 Destination Port : any 0 Scope : both Direction : inbound Logging control : no Fragment control : all packets Tunnel ID number : 1 Interface : all Auto-Generated : yes
These filter rules in addition to the default filter rules are activated by the mktun -v 4 -t 1 command.
To set up the other side, if another AIX machine, the tunnel definition can be exported on host A, then imported to host B.
exptun -v 4 -t 1 -f /tmp
This will export the tunnel definition into a file named ipsec_tun_manu.exp and any associated filter rules to the file ipsec_fltr_rule.exp in the directory indicated by the -f flag.
To create the matching end of the tunnel, the export files are copied to the remote side and imported into that remote AIX 4.3 machine by using the command:
imptun -v 4 -t 1 -f /tmp
where 1 is the tunnel to be imported and /tmp is the directory where the import files reside. This tunnel number is system generated and must be referenced from the output of the gentun command, or by using the lstun command to list the tunnels and determine the correct tunnel number to import. If there is only one tunnel in the import file, or if all the tunnels are to be imported, then the -t option is not needed.
If the remote machine is not AIX 4.3, the export file can be used as a reference for setting up the algorithm, keys, and SPI values for the other end of the tunnel.
Export files from the IBM Secure Network Gateway (SNG) can be imported to create tunnels in AIX 4.3. To do this, use the -n option when importing the file:
imptun -v 4 -f /tmp -n
Setting up an IBM tunnel is similar to a manual tunnel, but some of the choices are different for the crypto algorithms and the keys are negotiated dynamically, so there is no need to import keys. IBM tunnels are limited to Keyed MD5 for authentication. If the HMAC MD5 or HMAC SHA algorithms are desired, a manual tunnel must be used.
gentun -s 9.3.100.1 -d 9.3.100.245 -t IBM -e DES_CBC_8 -n 35564
As with manual tunnels, from this point the tunnel and filter table must be activated to make the tunnel active:
mktun -v 4 -t1
To set up the other side, if the other host is an AIX 4.3 IP Security machine, the tunnel definition can be exported on host A, then imported to host B.
exptun -v 4 -f /tmp
This will export the tunnel definition into a file named ipsec_tun_ibm.exp and any associated filter rules to the file ipsec_fltr_rule.exp in the directory indicated by the -f flag.
The procedure is the same for creating the second end of the tunnel on host B for an IBM tunnel. The tunnel definition is exported from host A and imported onto host B. The -n flag can be used for a file exported by an IBM Secure Network Gateway (SNG) or an IBM Firewall 3.1.
Filtering can be set up to be simple, using mostly autogenerated filter rules, or can be complex by defining very specific filter functions based on the properties of the IP packets. Matches on incoming packets are done by comparing the source address and SPI value to those listed in the filter table. Therefore, this pair must be unique.
Each line in the filter table is known as a rule. A collection of rules will determine what packets are accepted in and out of the machine, and how they will be directed. Filter rules can be written based on source and destination addresses and masks, protocol, port number, direction, fragment control, source routing, tunnel, and interface.
Below is a sample set of filter rules. Within each rule, fields are shown in the following order (an example of each field from rule 1 is shown in parentheses): Rule_number (1 ), Action (permit ), Source_addr (0.0.0.0 ), Source_mask (0.0.0.0 ), Dest_addr (0.0.0.0 ), Dest_mask (0.0.0.0 ), Source_routing (no ), Protocol (udp ), Src_prt_operator (eq ), Src_prt_value (4001 ), Dst_prt_operator (eq ), Dst_prt_value (4001 ), Scope (both ), Direction (both ), Logging (no ), Fragment (all packets ), Tunnel (0 ), and Interface (all ).
1 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no udp eq 4001 eq 4001 both both no all packets 0 all 2 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no ah any 0 any 0 both both no all packets 0 all 3 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no esp any 0 any 0 both both no all packets 0 all 4 permit 10.0.0.1 255.255.255.255 10.0.0.2 255.255.255.255 no all any 0 any 0 both outbound no all packets 1 all 5 permit 10.0.0.2 255.255.255.255 10.0.0.1 255.255.255.255 no all any 0 any 0 both inbound no all packets 1 all 6 permit 10.0.0.1 255.255.255.255 10.0.0.3 255.255.255.255 no tcp lt 1024 eq 514 local outbound yes all packets 2 all 7 permit 10.0.0.3 255.255.255.255 10.0.0.1 255.255.255.255 no tcp/ack eq 514 lt 1024 local inbound yes all packets 2 all 8 permit 10.0.0.1 255.255.255.255 10.0.0.3 255.255.255.255 no tcp/ack lt 1024 lt 1024 local outbound yes all packets 2 all 9 permit 10.0.0.3 255.255.255.255 10.0.0.1 255.255.255.255 no tcp lt 1024 lt 1024 local inbound yes all packets 2 all 10 permit 10.0.0.1 255.255.255.255 10.0.0.4 255.255.255.255 no icmp any 0 any 0 local outbound yes all packets 3 all 11 permit 10.0.0.4 255.255.255.255 10.0.0.1 255.255.255.255 no icmp any 0 any 0 local inbound yes all packets 3 all 12 permit 10.0.0.1 255.255.255.255 10.0.0.5 255.255.255.255 no tcp gt 1023 eq 21 local outbound yes all packets 4 all 13 permit 10.0.0.5 255.255.255.255 10.0.0.1 255.255.255.255 no tcp/ack eq 21 gt 1023 local inbound yes all packets 4 all 14 permit 10.0.0.5 255.255.255.255 10.0.0.1 255.255.255.255 no tcp eq 20 gt 1023 local inbound yes all packets 4 all 15 permit 10.0.0.1 255.255.255.255 10.0.0.5 255.255.255.255 no tcp/ack gt 1023 eq 20 local outbound yes all packets 4 all 16 permit 10.0.0.1 255.255.255.255 10.0.0.5 255.255.255.255 no tcp gt 1023 gt 1023 local outbound yes all packets 4 all 17 permit 10.0.0.5 255.255.255.255 10.0.0.1 255.255.255.255 no tcp/ack gt 1023 gt 1023 local inbound yes all packets 4 all 18 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no all any 0 any 0 both both yes all packets
Rule #1 is for the IBM Session Key daemon and will only appear in IP Version 4 filter tables. It uses port number 4001 to control packets for refreshing the session key. It is an example of how the port number can be used for a specific purpose. This filter rule should not be modified except for logging purposes.
Rules 2 & 3 are used to allow processing of Authentication Headers (AH) and Encapsulating Security Payload (ESP) headers. They should not be modified except for logging purposes.
Rules 4 &5 are a set of autogenerated rules that filter traffic between addresses 10.0.0.1 and 10.0.0.2 through tunnel #1. Rule 4 is for outbound traffic and rule 5 is for inbound traffic.
Rules 6 through 9 are a set of user-defined rules that filter outbound rsh, rcp, rdump, rrestore, and rdist services between addresses 10.0.0.1 and 10.0.0.3 through tunnel #2. Note that logging is set to yes so the administrator can monitor this type of traffic.
Rules 10 and 11 are a set of user-defined rules that filter both inbound and outbound icmp services of any type between addresses 10.0.0.1 and 10.0.0.4 through tunnel #3.
Rules 12 through 17 are user-defined filter rules that filter outbound FTP service from 10.0.0.1 and 10.0.0.5 through tunnel #4.
Rule 18 is an autogenerated rule always placed at the end of the table. In this case, it permits all packets that do not match the other filter rules. It may be set to deny all traffic not matching the other filter rules.
Each rule may be viewed separately (using lsfilt) to make each field clear. For example:
Rule 1: Rule action : permit Source Address : 0.0.0.0 Source Mask : 0.0.0.0 Destination Address : 0.0.0.0 Destination Mask : 0.0.0.0 Source Routing : yes Protocol : udp Source Port : eq 4001 Destination Port : eq 4001 Scope : both Direction : both Logging control : no Fragment control : all packets Tunnel ID number : 0 Interface : all Auto-Generated : yes
Below are listed all the parameters that can be specified in a filter rule:
See the AIX Version 4.3 Commands Reference for genfilt and chfilt for more information.
Certain rules are autogenerated for the use of the IP Security filter and tunnel code. These include the rules shown above for the session key daemon to refresh the keys in IBM tunnels (IP Version 4 only) and the rules for the processing of AH and ESP packets. Filter rules will also be autogenerated when defining tunnels. They will specify the source and destination address and mask values, as well as the tunnel ID. All traffic between those addresses will flow through the tunnel. Since the autogenerated rules permit all traffic over the tunnel, user defined rules may be necessary to place restrictions on certain types of traffic. These user defined rules should be placed before the autogenerated rules because the first rule that applies to the packet will be used. Below is an example of user defined filter rules that filter traffic based on ICMP operation.
1 permit 10.0.0.1 255.255.255.255 10.0.0.4 255.255.255.255 no icmp any 8 any 0 local outbound no all packets 3 all 2 permit 10.0.0.4 255.255.255.255 10.0.0.1 255.255.255.255 no icmp any 0 any 0 local inbound no all packets 3 all 3 permit 10.0.0.4 255.255.255.255 10.0.0.1 255.255.255.255 no icmp any 8 any 0 local inbound no all packets 3 all 4 permit 10.0.0.1 255.255.255.255 10.0.0.4 255.255.255.255 no icmp any 0 any 0 local outbound no all packets 3 all
Filter rules will be autogenerated when tunnels are defined. This is done to simplify the configuration of a single tunnel. This function can be suppressed by specifying the -g flag in gentun . You can find a sample filter file with genfilt commands to generate filter rules for different TCP/IP services in /usr/samples/ipsec/filter.sample.
Tunnel configurations allow a large number of parameters to be specified to ensure interoperability with other IP Security implementations. Some examples are given here to explain the functions that can be selected.
The packets will be formed using AH headers for authentication, ESP headers for encryption, or the new ESP header that allows both encrypted data and an authentication digest in the same packet (see figure). In the RFCs for AH and ESP defined in 1995, (RFC 1826 for AH and RFC 1829 for ESP), two headers were necessary to provide both authentication and encryption.
To configure a tunnel using DES CBC MD5, the combined ESP header is used with the ESP encryption algorithm set to DES_CBC_8 and the AH authentication algorithm set to HMAC MD5. To use this authentication algorithm, specify it with the -b flag, and its keys with the -c flag. For example:
gentun -v 4 -t manual -s 5.5.5.19 -d 5.5.5.23 -e DES_CBC_8 -b HMAC_MD5 -N 2349473
This command will generate a tunnel using DES CBC MD5 with autogenerated keys (see figure). The encrypted data and the authentication data are both contained in the same ESP header. It also supports replay preventions, which is not recommended for manual tunnels. It is included in this release for compatibility with other implementations and for testing purposes.
