Trusted Solaris Administration Overview

Routing in Trusted Solaris

In the Trusted Solaris operating environment, routes between hosts on different networks must maintain security at each step in the transmission.

Loading Routing Information at Boot Time

When a Trusted Solaris host boots, it loads routing information so that it can transmit data. If the file /etc/tsolgateways (which is maintained manually by the administrator) exists, then the gateways in the file serve as the host's defaults. If, however, /etc/tsolgateways does not exist, then the host uses the default routes from the file /etc/defaultrouter, which is also maintained manually by the administrator. If either file exists, then the host is said to use static routing.

If neither the /etc/tsolgateways nor the /etc/defaultrouter file exists, then the host uses dynamic routing and starts a special daemon, either in.rdisc(1M) (the network router discovery daemon) or in.routed(1M) (the network routing daemon). If the host also serves as a gateway, that is, a host that connects to two or more networks, then both in.rdisc and in.routed are started.

Route Tables in the Trusted Solaris Environment

The main objective for routing is to find the shortest secure route between two hosts. Trusted Solaris routing tables are based on extended metrics (called emetrics). An emetric is a combination of a routing metric and Security Routing Information (SRI), for measuring security. The SRI can incorporate these security attributes:

This information is propagated by the routing daemon in.routed using the Trusted Solaris-extended Routing Information Protocol if dynamic routing is used, or if static routing is used, by manual entry using the route command or through the /etc/tsolgateways or /etc/defaultrouter files. The emetric for a particular route is used for accreditation checks when this route is being considered.

Not every route in the routing table must have an emetric. If a route does not have an emetric, the remote host template of its first hop gateway is used for the accreditation check instead.

Accreditation Checks

To determine the suitability of a route regarding security, the Trusted Solaris environment runs a series of tests called accreditation checks on the source host, destination host, and the route's emetrics. If the emetric for a particular route is missing, the security attributes for the first-hop gateway in the route are checked. A host's security attributes are derived from information in the tnrhdb, tnrhtp, and tnidb files. The tests check, for example, that a data packet's label is within the range of each host in the route.

Source Accreditation Checks

The accreditation checks conducted on the source host are:

Gateway Accreditation Checks

The accreditation checks conducted on a Trusted Solaris gateway host work in the following manner:

If the next hop is an unlabeled host, then the label of the source host must match the label of the destination host.

If the packet has the CIPSO option, the following conditions for forwarding must be true:

If the packet has the RIPSO option, the following conditions for forwarding must be true:

Destination Accreditation Checks

When a Trusted Solaris machine receives data, the trusted network software checks for the following:

After the data has passed the accreditation checks above, the system checks that all necessary security attributes are present. If security attributes are missing, the system looks up the source host (by its IP address or a target expression) in the tnrhdb database to get the name of the network security template assigned to the host. The system then retrieves the template's set of security attributes from the tnrhtp database. If security attributes are still missing, the software looks up the network interface in the tnidb database and retrieves default security attributes.

Routing Example

An example of routing in the Trusted Solaris environment is shown below. Figure 3-4 shows the routing diagram and shows the routing table. There are three potential routes between Host 1 and Host 2.

Figure 3-4 Typical Trusted Solaris Routes and Routing Table

Graphic

Route 

First hop gateway 

RIP Metric 

Min Label 

Max Label 

DOI 

CIPSO 

Gateway 1 

 

 

Gateway 3 

ADMIN_LOW

ADMIN_HIGH

 

Gateway 5 

 

 

 

 

Using Routing Commands

To display the contents of the routing table, use the netstat --R command. To make a manual change to the routing table, use the route command with the add or delete option. For example, the following route command adds to the routing table a loop with the hosts at 129.150.115.0 and 129.150.118.39 with a distance metric of 2, a Label range from C to TS, a RIPSO label = top_secret sci, and a RIPSO error = genser;sci.

$ route add net 129.150.115.0 129.150.118.39 \
-m metric=2,min_sl=c,max_sl=ts,ripso_label="top_secret sci",\
ripso_error="genser;sci"

add net 129.150.115.0: gateway 129.150.118.39

To see the results of the added loop, type:

$ netstat -Rn
...
129.150.115.0        129.150.118.39        UG       0      0  
        metric=2,min_sl=C,max_sl=TS,
        ripso_label=0x3d 0x20000000 (top_secret sci),
        ripso_error=0xa0000000 (genser;sci)
...

The new route is shown above. The other routes are replaced by ellipses (...). A second example of adding a route with two new emetrics and viewing the new routing table follows:

$ route add net 129.150.114.0 129.150.118.39 \ 
-m metric=3,min_sl=admin_low,max_sl=s,doi=3 \
-m metric=4,min_sl=c,max_sl=admin_high,doi=4,\
ripso_label="top_secret sci",ripso_error="genser;sci"

add net 129.150.114.0: gateway 129.150.118.39
$ netstat -Rn
...
129.150.115.0        129.150.118.39        UG       0      0  
        metric=2,min_sl=C,max_sl=TS,
        ripso_label=0x3d 0x20000000 (top_secret sci),
        ripso_error=0xa0000000 (genser;sci)
129.150.114.0        129.150.118.39        UG       0      0  
        metric=4,min_sl=C,max_sl=ADMIN_HIGH,doi=4,
        ripso_label=0x3d 0x20000000 (top_secret sci),
        ripso_error=0xa0000000 (genser;sci),
        metric=3,min_sl=ADMIN_LOW,max_sl=S,doi=3
...

Routing Through Non-Trusted Solaris Gateway Clusters

Secure data can be routed through clusters containing non-Trusted Solaris gateways. This procedure is called tunneling. For our purposes, a cluster is a contiguous set of either Trusted Solaris hosts and gateways only, or non-Trusted Solaris hosts and gateways only. An edge gateway is a gateway (Trusted Solaris or non-Trusted Solaris) that connects a cluster to a cluster of the other type.

The following figure shows an example of tunneling. The shaded rectangles represent non-Trusted Solaris gateways. The loops with thick lines indicate clusters. Cluster #1 is a non-Trusted Solaris cluster; cluster #2 is a Trusted Solaris cluster.

Figure 3-5 Tunneling Example

Graphic

To transmit data from host #1 to host #2 requires a route through cluster #1, a non-Trusted Solaris cluster, and cluster #2, a Trusted Solaris cluster. This is permitted under the following two conditions only: