Overview of Routing in Trusted Extensions

In Trusted Extensions, routes between hosts on different networks must maintain security at each step in the transmission. Trusted Extensions adds extended security attributes to the routing protocols in the Oracle Solaris OS. Unlike the Oracle Solaris OS, this Trusted Extensions release does not support dynamic routing. For details about specifying static routing, see the -p option in the route(1M) man page.

Gateways and routers route packets. In this discussion, the terms “gateway” and “router” are used interchangeably.

For communications between hosts on the same subnet, accreditation checks are performed at endpoints only because no routers are involved. Label range checks are performed at the source. If the receiving host is running Trusted Extensions software, label range checks are also performed at the destination.

When the source and destination hosts are on different subnets, the packet is sent from the source host to a gateway. The label range of the destination and the first-hop gateway is checked at the source when a route is selected. The gateway forwards the packet to the network where the destination host is connected. A packet might go through several gateways before reaching the destination.

Background on Routing

On Trusted Extensions gateways, label range checks are performed in certain cases. A Trusted Extensions system that is routing a packet between two unlabeled hosts compares the default label of the source host to the default label of the destination host. When the unlabeled hosts share a default label, the packet is routed.

Each gateway maintains a list of routes to all destinations. Standard Oracle Solaris routing makes choices to optimize the route. Trusted Extensions provides additional software to check security requirements that apply to the route choices. The Oracle Solaris choices that do not satisfy security requirements are skipped.

Routing Table Entries in Trusted Extensions

The routing table entries in Trusted Extensions can incorporate security attributes. Security attributes can include a cipso keyword. Security attributes must include a maximum label, a minimum label, and a DOI.

For entries that do not provide security attributes, the attributes in the gateway's security template are used.

Trusted Extensions Accreditation Checks

Trusted Extensions software determines the suitability of a route for security purposes. The software runs a series of tests called accreditation checks on the source host, the destination host, and the intermediate gateways.

The accreditation check verifies the label range and CIPSO label information. The security attributes for a route are obtained from the routing table entry, or from the security template of the gateway if the entry has no security attributes.

For incoming communications, the Trusted Extensions software obtains labels from the packets themselves, whenever possible. Obtaining labels from packets is only possible when the messages are sent from systems that support labels. When a label is not available from the packet, a default label is assigned to the message from trusted networking database files. These labels are then used during accreditation checks. Trusted Extensions enforces several checks on outgoing messages, forwarded messages, and incoming messages.

Source Accreditation Checks

The following accreditation checks are performed on the sending process or sending zone:

• For all destinations, the label of the data must be within the label range of the next hop in the route, that is, the first hop. And, the label must be contained in the first-hop gateway's security attributes.

• For all destinations, the DOI of an outgoing packet must match the DOI of the destination host. The DOI must also match the DOI of all hops along the route, including its first-hop gateway.

• When the destination host is an unlabeled host, one of the following conditions must be satisfied:

  • The sending host's label must match the destination host's default label.

  • The sending host is privileged to perform cross-label communication, and the sender's label dominates the destination's default label.

  • The sending host is privileged to perform cross-label communication, and the sender's label is ADMIN_LOW. That is, the sender is sending from the global zone.

Gateway Accreditation Checks

On a Trusted Extensions gateway system,the following accreditation checks are performed for the next-hop gateway:

• If the incoming packet is unlabeled, the packet inherits the source host's default label from the tnrhdb entry. Otherwise, the packet receives the indicated CIPSO label.

• Checks for forwarding a packet proceed similar to source accreditation:

  • For all destinations, the label of the data must be within the label range of the next hop. And, the label must be contained in the security attributes of the next-hop host.

  • For all destinations, the DOI of an outgoing packet must match the DOI of the destination host. The DOI must also match the DOI of the next-hop host.

  • The label of an unlabeled packet must match the destination host's default label.

  • The label of a CIPSO packet must be within the destination host's label range.

Destination Accreditation Checks

When a Trusted Extensions host receives data, the software performs the following checks:

• If the incoming packet is unlabeled, the packet inherits the source host's default label from the tnrhdb entry. Otherwise, the packet receives the indicated CIPSO label.

• The label and DOI for the packet must be consistent with the destination zone or destination process's label and DOI. The exception is when a process is listening on a multilevel port. The listening process can receive a packet if the process is privileged to perform cross-label communications, and the process is either in the global zone or has a label that dominates the packet's label.