Additional filtering criteria based on network attributes

Some filtering criteria are inferred from the external characteristics of the IP traffic, rather than being found in the actual IP packet. The following additional attributes are used to distinguish IP packets:

• Direction

  The direction of an IP packet is either inbound or outbound.

• Routing

  The routing attribute of an IP packet is either local or routed. IP packets are considered local if either of the following conditions is true:

  • The packet is inbound and the destination address in the IP packet exists on the IPSECURITY stack.
  • The packet is outbound and the source address in the IP packet exists on the IPSECURITY stack.
  Otherwise the IP packet is considered routed.
• Security class

  Each non-virtual interface on a z/OS® system is assigned a security class. The security class of an IPv4 interface is determined by the SECCLASS parameter that is coded on the LINK statement or the DYNAMICXCF parameter of the IPCONFIG statement in the TCP/IP profile. The security class of an IPv6 interface is determined by the SECCLASS parameter that is coded on the INTERFACE statement or the DYNAMICXCF parameter of the IPCONFIG6 statement in the TCP/IP profile. The value of SECCLASS is a number in the range 1-255. If SECCLASS is not specified for an interface, the interface has a default security class of 255.

  Each IP packet entering or leaving the system inherits the security class of the interface that it traverses:

  • For inbound traffic, this is the interface on which the packet arrived.
  • For outbound traffic, this is the interface over which the packet is sent.

  The value for SECCLASS has no inherent meaning. A SECCLASS of 255 is no more or less secure than a SECCLASS of 1. You can optionally assign a SECCLASS value either to uniquely identify an interface, or to group interfaces with similar security requirements, based on site policy. Consequently, this attribute can be used as an additional criterion for IP filtering. Security class can be used to define broad filter rules that encompass all of the IP traffic that uses a group of interfaces without explicit knowledge of network addressing, or to ensure that an IP packet arrived on a valid interface.

  For example, as shown in Figure 1, consider a z/OS system with three physical interfaces that are assigned the following security classes:

  I1: SECCLASS 10
  I2: SECCLASS 20
  I3: SECCLASS 20

  Figure 1. Using SECCLASS to identify interfaces

  

  All IP packets from NET1 and NET2 have the same security class (10), and all IP packets from NET3 and NET4 have the same security class (20). Even though each interface on the z/OS system can reach multiple networks, you can configure a single IP filter rule that matches all of the IP traffic from NET3 and NET4 without explicitly identifying any attributes of the IP packets, other than security class. For instance, if NET3 and NET4 are trusted internal networks in which you want to allow all network traffic, you can configure one IP filter rule permitting all traffic with a security class of 20, without regard to IP address.

  An IP filter using security class as a criterion is not limited to scenarios in which the IP addresses are ignored. To counter IP address spoofing, IP filter rules can take into account both security class and IP address. IP address spoofing involves the creation of an IP packet whose source address has been modified to reflect an address other than that of the originator. Because routers ignore the source address when making routing decisions, the modified IP packet can still reach its destination. An IP packet whose source IP address has been spoofed is usually not legitimate and is often used in a malicious manner. IP filtering can counter an attempt to spoof a source IP address by ensuring that an IP packet arrived on a valid network interface. For instance, any inbound packet that has a source address of an internal network node, but entered the system though an external interface, is probably spoofed and should be denied.

  Rule: The SecurityClass parameter cannot be used on an IpFilterRule statement with a dynamic ipsec action. The IKE protocols do not provide for the negotiation of SecurityClass, and therefore it cannot be used as a selection criterion for a Security Association. The SecurityClass parameter can be configured only for an IpFilterRule statement that has an action of permit, deny, or manual ipsec. Coding a SecurityClass parameter with a value other than 0 on a dynamic ipsec rule is considered a configuration error.
  Guidelines:

  • If there are multiple interfaces by which a packet can reach its destination, the SECCLASS values for the interfaces and the filter rules should be consistent. If a packet could reach its intended destination by traversing one of a number of interfaces, the SECCLASS values and the related filter rules should account for the possibility of alternate routing.
  • If the same IPv6 link-local address exists in multiple LANs in your network and you want to define filter rules to distinguish these IP addresses, configure different SECCLASS values for the interfaces onto these LANs to make the filter rules unique. However, if you are using dynamic IPSec for link-local addresses, you cannot use SECCLASS values to make the filter rules unique, so you must ensure that there are no overlapping or duplicate link-local addresses.

  For more details about the SecurityClass parameter on the IpService statement, the SECCLASS parameter on the LINK and INTERFACE statements, and the SECCLASS keyword on the DYNAMICXCF parameter of the IPCONFIG and IPCONFIG6 statements, see z/OS Communications Server: IP Configuration Reference.

• Remote IKE identity

  For traffic that is protected by IPSec, the remote IKE identity can be used as a filtering criterion. This is particularly useful in cases where a client is roaming or mobile and does not have a fixed IP address, but has a known authenticated IKE identity.

  Filter rules with a remote IKE identity often have wildcard IP addresses that are not very specific, because mobile users can connect from a variety of locations.

  Guidelines:

  • Consider placing filter rules with a remote IKE identity near the bottom of your IP filter policy, so that other traffic has optimal filter searching. Because the wildcard IP addresses are not very specific for these rules, much IP traffic needs to be compared against these rules to test whether the traffic matches the rule.
  • Consider whether the mobile client's traffic might intersect with other filter rules; for example, when a mobile user occasionally brings their laptop into the office. If you choose to permit the user to continue to establish their IPSec connection while in the office, then you should order the remote identity filter rules in your IP filter policy so that they precede the office network filter rules.