test

Trusted Solaris Administrator's Procedures

Chapter 7 Managing Computers and Networks

This chapter describes in detail the concepts and goals of trusted networking. For an overview of trusted networking, see "Administering Trusted Networking" in Trusted Solaris Administration Overview.

Managing Trusted Network Communications

The Trusted Solaris operating environment supports network communications between Trusted Solaris computers and any of the following types of computers:

Network communications and services are managed by several Trusted Solaris subsystems.

SMC Tools for Administering Computers and Networks

The SMC Trusted Solaris Configuration toolbox contains the following tools for configuring computers and networks and defining security attributes for computers, networks, and network interfaces:

The Computers and Networks and the Interface Manager tools are shown in the following figure.

Figure 7-1 Solaris Management Console Tools

Graphic

Meeting the Goals of Trusted Networking

The overall goal of trusted networking software is to ensure that the Trusted Solaris security policy is enforced even when the subjects (processes) and objects (data) are located on different hosts.

Assigning security attributes to computers and networks and to mounted file systems ensures the following:

Understanding Security Attributes Assigned to Computers

Security attributes are administratively assigned to computers (hosts and routers) by means of templates. The Security Administrator role administers templates and assigns templates to computers using the Security Families tool. If a computer does not have a template assigned, no communications are allowed with that computer. Computers that share the same template are considered to be part of the same security family.

Every template has a Host Type, which determines which protocol is used to communicate with the computer that is assigned the template. The protocols tell the kernel which security attributes to look for in the header of an incoming packet or to insert into an outgoing packet. See "Host Types".

Every template also has an Accreditation Range (consisting of a Minimum Label and a Maximum Label) and a default DOI (Domain of Interpretation). For details about these attributes, see "Computer Accreditation Range" and "Domain of Interpretation (DOI)".

Each host type has its own set of additional required and optional security attributes, which are introduced in the following list:

For more about specifying an IP label or how to change the default DOI, see "Advanced Security Attributes".

Host Types

The following table describes the host types for which entries can be made in the trusted network databases. The first column shows the name used in the Security Families host type menu.

Table 7-1 Host Types, Protocols, and Notes

Name in Template Manager 

Protocols and Notes 

Trusted Solaris  

The TSOL protocol simplifies passing security attributes between computers running Trusted Solaris 2.5.1, Trusted Solaris 7, Trusted Solaris 8, or Trusted Solaris 8 4/01 releases. TSOL is a derivative of the TSIX(RE) 1.1 - SAMP protocol that passes the security attributes in a similar place in the network protocol stack and uses similar header structures. The TSOL protocol passes security attributes in binary form and thus does not require token mapping. NOTE: For communications between Trusted Solaris computers, either the Trusted Solaris or TSIX host type can be assigned in the templates, depending on whether you want the labels to be transmitted in binary form or in token form. If only the labels' names differ on two computers while the labels' binary representations are the same, the Trusted Solaris host type can be used. If the labels' names are the same but the labels' binary representations are different on both Trusted Solaris computers, the TSIX host type can be assigned.  

Unlabeled 

This host type is assigned to computers running Solaris or other unlabeled operating environments to specify a default label and default clearance to apply to communications with the unlabeled computer. Also, a minimum and maximum label can be set to allow the sending of packets to an unlabeled gateway for forwarding when the packets' labels do not match the default label and would therefore not be sent to the computer as a destination. 

RIPSO  

Revised IP Security Option (RIPSO) described in the IETF RFC 1108. It specifies a DoD IP labeling method to incorporate labels into IP packets, which are then used for network mandatory access control checks. A fixed RIPSO label specified in the template is applied to network packets interchanged with the particular host. Though this functionality does not fully meet the RFC specifications, it is expected to supply sufficient functionality where RIPSO labels are needed. 

CIPSO  

Common IP Security Option (CIPSO) protocol TSIX(RE) 1.1 is used to specify security labels that are passed in the IP options field. CIPSO labels are derived automatically from the data's label. Tag type 1 is used to pass the CIPSO security label. This label is then used to make security checks at the IP level and to label the data in the network packet.  

TSIX  

Trusted Security Information Exchange for Restricted Environments (TSIX/RE) protocol uses token mapping to pass security attributes. Can be used for computers running the Trusted Solaris or other TSIX-cognizant operating environments. See the NOTE for the Trusted Solaris host type in the first entry in this table. 

Computer Accreditation Range

The Minimum Label and the Maximum Label are used in the following ways:

Domain of Interpretation (DOI)

A default Domain of Interpretation is assigned in the default templates for all host types. Two computers need to have the same DOI in order to communicate. Organizations with the same DOI need to agree among themselves about how labels and other security attributes are to be interpreted. Each host type has a DOI associated with it. By default each existing or new template has the default DOI specified in the DOI field. You do need to change the default DOI unless you have reasons for wanting to do so.

As mentioned under "Host Types", either the Trusted Solaris or TSIX host type can be specified in templates assigned to Trusted Solaris computers. If the NOTE in the first entry in Table 7-1 is true for your site, the Trusted Solaris or TSIX host-type computers can share the same DOI .

DOIs in Trusted Solaris IPv4 Packets

In Trusted Solaris IPv4 packets, the DOI is carried in the packet along with the label. In an IPv4 packet, the specified DOI is included both with the IP options (if any are specified) and in the SAMP header.

Headers ( Options [IP options including DOI] ) 

SAMP including DOI  

Data 

DOIs in Trusted Solaris IPv6 Packets

Note -

Trusted routing using IP labels is not supported with IPv6.

In Trusted Solaris IPv6 packets, label information is carried in multilevel security (MLS) options portion of the packet's Headers. Because label information is in the Headers portion of the packet, the packet's label can be used for routing.

Headers ( Options [SAMP MLS options including DOI] 

Data 

To specify a DOI other than the default, use the Advanced Security Attributes tabs.

Default Label

Each unlabeled or RIPSO-type computer is assigned a single label in the Default Label field. The Default Label assigned to an unlabeled or RIPSO-type computer should reflect the level of trust that is appropriate for the computer and its users. For RIPSO hosts, the Default Label should be the same as the RIPSO Label (which is a combination the RIPSO Send Class and the RIPSO Send PAF).

Default Clearance

Each single-label computer (with the Unlabeled or RIPSO host type) is assigned a clearance in the Default Clearance field. The clearance sets the upper limit for write operations performed on the Trusted Solaris computer by someone on the unlabeled host. For example, on an unlabeled computer with a Default Label of CONFIDENTIAL and Default Clearance of SECRET, a user who is working on a file system mounted from a Trusted Solaris host can open an upgraded file with a label of SECRET and write into it (if the file's name is known to that user).

Forced Privileges

One or more privileges can be specified in the Forced Privileges field of a template that has the unlabeled host type. An unlabeled computer does not recognize privileges. Specifying privileges in this field affects only how the Trusted Solaris computer handles requests from a program that is running on the unlabeled computer. Privileges can be specified to allow a client from an unlabeled computer to do something not otherwise permitted, such as reading a file whose label dominates that of the client or communicating with X clients owned by another user.

Allowed Privileges

Remote Trusted Solaris computers can usually be trusted to provide correct privileges. If needed, the privileges that a remote Trusted Solaris computer is allowed to use can be controlled by specifying a restricted set of privileges in the Allowed Privileges field of a template with the Trusted Solaris host type. Processes running on a remote Trusted Solaris system communicate their effective privileges as part of their security attributes. You can locally restrict those privileges to the ones that are specified in the Allowed Privileges set.

Advanced Security Attributes

The Advanced Security Attributes tab in the Security Families Template dialog box sets the following options.

Using IP Labels in Trusted Routing

If a computer has an IP Label type of RIPSO or CIPSO specified in its template, the specified type of IP label is put into outgoing packets, and the incoming packets from the specified host must contain an IP label of the specified type. IP labels can be used for trusted routing. Packets with an IP label are only forwarded to routers whose label range allows the specified IP label.

Some organizations have the requirement to label all of their packets with RIPSO or CIPSO labels, unless the packets are being sent to unlabeled computers directly connected to the network. Others need to use IP labels for trusted routing of packets going to certain destination hosts. In a homogeneous Trusted Solaris security domain, this is accomplished by assigning a template with the Trusted Solaris host type and an IP label of either RIPSO or CIPSO to all or some Trusted Solaris computers.

Similarly a template with the TSIX host type can also be configured with CIPSO or RIPSO labels to achieve the same labeling of packets for TSIX hosts.

And, of course, packets to and from a host assigned a template with a CIPSO or RIPSO host type carry either a CIPSO or RIPSO IP label. The IP Options supported in the templates for the Unlabeled host type provide a way to label packets coming into a Trusted Solaris security domain from unlabeled computers. Unlabeled packets become labeled when they pass through Trusted Solaris/ripso or Trusted Solaris/cipso gateways on their way to other Trusted Solaris/ripso or Trusted Solaris/cipso computers. The RIPSO or CIPSO labels are stripped from packets before they are delivered to unlabeled computers, which are typically outside the security domain. To accomplish this, administrators can specify an IP label of RIPSO or CIPSO in the template for an unlabeled host.

Default Templates

Trusted Solaris software ships with a set of templates that matches the label_encodings(4) file on the installation disk. Icons for all defined templates appear when the Security Families tool is double-clicked. The Security Families tool enforces the required fields in the templates, based on the host type.

Caution - Caution -

If your site has installed its own label encodings, you must modify the templates to work with your labels.

The simplest and safest configuration is to enable communication only among Trusted Solaris computers that share the same label_encodings file. To set up such a configuration, the System Administrator role can assign the default TSOL template or other similar template with the Trusted Solaris host type to all Trusted Solaris computers.

Default Templates for Trusted Solaris Systems

A computer running Trusted Solaris 2.5.1 and later compatible releases can be assigned any template that has the Trusted Solaris host type. See the online help in the Security Families tool for a description of the default templates for the Trusted Solaris host type.

Default Templates for Unlabeled or RIPSO Computers

The Trusted Solaris environment supports communications with computers running operating environments that do not recognize labels (such as the Solaris operating environment). A computer that does not recognize labels or that uses RIPSO labels must be assigned a single label and a clearance. The label and clearance restrict communications with that computer. Before assigning a template that has the Unlabeled or RIPSO host type to an unlabeled host, specify the following:

Caution - Caution -

When creating or modifying a template for an unlabeled or RIPSO-type computer, do not forget to change the default label to reflect the level of trust it should be accorded. Administrators who report problems with not being able to communicate with remote single-label computers at the expected label have usually forgotten to specify that label in the Default Label field.

The default unlabeled and ripso host type templates are valid only when either the default label_encodings file is used or another label encodings file with the same label names and binary representations for the labels. See the online help in the Security Families tool for descriptions of the default unlabeled or RIPSO templates.

Do not use the admin_low template during normal system operations. The admin_low template is needed during initial boot only, before the system is configured. The template assignment is stored in the tnrhtp and tnrhdb databases in /etc/security/tsol on the installed machine. Once the system is configured, the Security Administrator role should either remove the 0.0.0.0 entry entirely or change it to assign a template with an appropriate hots type and security attributes.

Wildcard Entry and Prefix Length

A wildcard IP address is the IP address of a subnetwork. A subnetwork is defined by its IP address and its netmask. The netmask determines the prefix that has to be common to all the addresses belonging to a subnetwork.

For example, the IP address 192.168.123.0 is a wildcard with a netmask = 255.255.255.0. The subnet is made up of all the IP addresses between 192.168.123.1 and 192.168.123.255. A optional Prefix Length can be specified in the form of an integer. The prefix length determines the size of the subnet and is the number of 1 bits in the netmask.

Table 7-2 Wildcard Address, Netmask, and Prefix Length

class A addresses: a.0.0.0, or a 

class B addresses: a.b.0.0, or a.b  

class C addresses: a.b.c.0, or a.b.c  

netmask = 255.0.0.0 

netmask = 255.255.0.0 

netmask = 255.255.255.0 

prefix length = 8  

prefix length = 16  

prefix length = 24 

With variable-length subnetting, the prefix length does not have to be a multiple of 8. For example, you can have the IP address 192.168.123.224, with a netmask = 255.255.255.224, and a prefix length = 27, covering the addresses between 192.168.123.225 and 192.168.123.255. IPv4 network addresses can have a prefix length between 1 and 32. IPv6 network addresses can have a prefix length between 1 and 128.

The trusted network software looks first for an entry that specifically assigns the host to a template, and if it does not find a specific entry, the software looks for the subnetwork entry that best matches the hosts's IP address (a subnetwork with the longest prefix length to which that address belongs).

If a computer's IP address cannot be matched to an entry, communication with that computer is not permitted.

A default 0.0.0.0 entry matches all computers that are not otherwise matched by other entries.

Sites that need to strictly control remote access should remove the 0.0.0.0 entry. They should also assess whether to use any wildcard addresses. For more information, see the tnrhdb(4) man page.)

CIPSO Labels in Packets

The CIPSO label is derived from the actual label of the data on the sending Trusted Solaris computer.

The trusted networking software puts a CIPSO label and a DOI (domain of interpretation) number into the IP option for outgoing packets and also looks for a CIPSO label and DOI in the IP option of incoming packets, if the trusted network template entry assigned to the remote host meets one of these criteria:

The CIPSO label that is inserted into outgoing packets is derived by the trusted networking software from the actual label associated with the data. Sometimes Trusted Solaris labels match directly to a CIPSO label. For example, the label of CONFIDENTIAL matches the CIPSO label of CONFIDENTIAL. However, most Trusted Solaris labels do not map directly to CIPSO labels.

Note -

At a site that plans to use CIPSO labels for trusted routing or wishes to communicate with a host with a host type of CIPSO, the Security Administrator role should plan ahead to configure the site's labels so they map well to CIPSO labels.

A DOI (domain of interpretation) must also be specified, and the same DOI must be:

Ensuring Labels Are Mappable to CIPSO Labels

The Security Administrator role needs to plan ahead to ensure that the labels defined in the label_encodings(4) file map well to CIPSO labels. See Trusted Solaris Label Administration.

RIPSO Labels in Packets

The RIPSO, Revised IP Security Option, protocol is described in the IETF RFC 1108. The trusted networking software puts a RIPSO label into the IP option for outgoing packets and also looks for a RIPSO label in the IP option of incoming packets from a host, if the trusted network template entry for the host meets one of these criteria:

RIPSO labels on outgoing packets are administratively defined. The Security Administrator role specifies them in the tnrhtp database, putting the classification in the RIPSO Send Class field and the compartment(s), or protection authority flags (PAF) in the RIPSO Send PAF field.

The following RIPSO Send classifications are supported: Top_Secret, Secret, Confidential, and Unclassified.

The RIPSO Send PAF and Return PAF fields refer to Protection Authority Flags, which are shown in the following table. PAFs specified in the Send PAF field are used like compartment names along with the classification within the RIPSO labels (as in Top_Secret SCI). PAFs specified in the Return PAF field are used in labeling ICMP messages that can be generated as errors in response to incoming RIPSO labeled packets. The classification sent back in an ICMP message is the same as the RIPSO classification in the packet.

Table 7-3 Protection Authority Flags
 Protection Authority Flags (may be specified along with supported classifications in RIPSO labels or specified as RIPSO errors)
GENSER
SIOP-ESI
SCI
NSA
DOE

Understanding Security Attributes Assigned to Network Interfaces

All interfaces on a computer running Trusted Solaris software are automatically detected by the trusted network software and assigned a default set of attributes. The Interface Manager shown below is used only when the Security Administrator role wants to change the defaults for an interface.

The default attributes are shown in the following table:

Default Label 

Minimum Label 

Maximum Label 

Default Clearance 

Forced Privileges 

ADMIN_LOW 

ADMIN_LOW 

ADMIN_HIGH 

ADMIN_HIGH 

None 

Summary - Any values specified for a computer in a template take precedence over any values supplied for the network interface, and if no values are specified, system defaults apply. For example, if computer A is assigned a default label of INTERNAL, while the network interface that is connected to the network where computer A resides is assigned a default label of PUBLIC, the data coming from computer A is assigned the INTERNAL label. The default label assigned by the network interface is not used.

Network Interface Accreditation Range

The Minimum Label and the Maximum Label are used to set the range of labels for data that can be sent through the interface.

Note -

Full communications within a Trusted Solaris domain require an accreditation range of ADMIN_LOW to ADMIN_HIGH.

To be able to leave certain fields empty in a single template assigned to one computer or to a group of computers that is accessed through the same network interface, the Security Administrator role can specify the values in an entry that applies to that network interface.

The entries assigned to network interfaces are looked at only if certain fields are left empty in the template assigned to a computer. If a value is not found either in the template that covers the host or in an entry that applies to the interface through which the remote computer is accessed, then a set of default values is applied.

Note -

Restrict the accreditation range on a network interface with care. Network services fail unless the network interface is configured with an accreditation range that includes the labels upon which those services depend. For example, audit clients cannot write ADMIN_HIGH audit data onto the audit server unless the ADMIN_HIGH label is in the range. Full communications within a Trusted Solaris domain require an accreditation range of ADMIN_LOW to ADMIN_HIGH.

Default Security Attributes

The Default Label, Default Clearance, and optional Forced Privileges in the Interface Manager are rarely useful. They would be used when a Trusted Solaris computer is communicating with a computer that is running an operating system that does not recognize labels or privileges, such as the Solaris operating environment, and then only if the same fields have been left empty in the template that applies to the single-label computer. For example, the Security Administrator role might create an entry for a second interface on the local computer that would apply the same label, clearance, and optional forced privileges to all computers running Solaris on the network that is connected to the second interface. These fields could then be left empty in any templates that cover the computers (as specified in the Security Families tool in Computers and Networks).

Default Label

The Default Label should reflect the level of trust that is appropriate for the computer and its users.

Default Clearance

The Default Clearance sets the upper limit for write operations performed on the Trusted Solaris computer by someone on the unlabeled computer. For example, on an unlabeled computer with a Default Label of CONFIDENTIAL and Default Clearance of SECRET, a user who is working on a file system mounted from a Trusted Solaris computer can open an upgraded file with a label of SECRET and write into it (if the file's name is known to that user).

Forced Privileges

An unlabeled computer does not recognize privileges. Specifying privileges in the Forced Privileges field affects only how the Trusted Solaris system handles requests from a program that is running on the unlabeled computer. Specifying privileges enables a client from an unlabeled computer to do something not otherwise permitted, such as reading a file whose label dominates that of the client or communicating with X clients owned by another user. If the corresponding values are set in a template that covers the computer, the value in the template takes precedence over the values specified for the network interface.

The following describes whose values are used for a network interface:

  1. Is the needed value specified in a remote host template?

    1. If yes, the value in the template is used

    2. If no, is the needed value specified in an entry for the interface?

      1. If yes, use the value specified for the interface.

      2. If no, use the default value.

Accreditation Checks

The trusted networking software performs accreditation checks to compare the security attributes of the source host, the destination host, and of the routes along the way.

Security attributes for the accreditation range check (accreditation range and any CIPSO or RIPSO label information that may be specified) are obtained from a host's templates. The security attributes for a route (its SRI) are obtained from the route's emetric in the routing table. If an emetric for a route has not been specified, the security attributes of the first hop gateway host's entries are checked.

On a router, accreditation checks are performed only if the packet to be forwarded has RIPSO or CIPSO labels and then the labels in the IP options portion of the packet are used. If the packet has a CIPSO label, its label is compared to the label range of the incoming and outgoing interface. Its label is also compared to the label range of the next hop gateway.

MAC Enforcement on Outgoing Messages

The following accreditation checks are performed on the sending host.

Note -

A first hop check occurs when a message is being sent from a host on one network to a host on another through a gateway.

MAC Checks on Messages Being Forwarded

On a Trusted Solaris gateway, accreditation checks are performed for the next hop and for the network interfaces.

If the packet has CIPSO label information, the following must be true for a packet to be forwarded:

If the packet has RIPSO label information, the following must be true for a packet to be forwarded:

If the label of a message is not within the minimum and maximum labels specified in the accreditation range for any of the destination host, gateways, or the network interface, the message is dropped.

MAC Enforcement on Incoming Messages

The following checks are performed on a receiving host.

For incoming communications, the Trusted Solaris networking software obtains labels and other security attributes from the packets themselves whenever possible--which is only completely possible when the messages are sent from systems that support labels and all the other required attributes in a form recognized by the Trusted Solaris software. In many cases, packets arrive from hosts that are not label-cognizant or that do not send recognizable labels, or the packets do not have all of the other required attributes in their packets.

When the needed security attributes are not all available from a packet, those that are lacking are assigned to the message from trusted networking databases. Any attributes not obtainable from the host's entry are supplemented by the attributes specified in the entry in the trusted network interface database entry the interface through which the message arrives.

Administering Routing

Some sites may restrict communications outside of the local network to a single label for publicly-available information, such as UNCLASSIFIED or PUBLIC. These sites specify the desired single label as both the maximum and minimum label assigned to the network interface that is connected to the external network. The Trusted Solaris environment supports additional methods for routing communications between networks, so that the Security Administrator role can set up routes that enforce the degree of security required by the site's security policy. See the TCP/IP and Data Communications Administration Guide for more details about TCP/IP and routing.

Background on Routing

For communications sent to destinations on the same subnet, accreditation checks are performed by Trusted Solaris endpoints only since no routers are involved. (Because gateways and routers route packets, the terms gateway and router are used interchangeably in this discussion.) Accreditation range checks are performed at the source. If the receiving host is running Trusted Solaris, accreditation range checks are also performed at the destination.

When the source and destination hosts are on two different sub-networks, the packet is sent from the source host to a gateway. The accreditation range of the destination and of the first hop gateway is checked at the source when selecting a route. The gateway forwards the packet to the network where the destination host is connected. A packet may go through a number of gateways before reaching the destination.

On Trusted Solaris gateways, accreditation range checks are performed in certain cases. A Trusted Solaris computer routing a packet between two unlabeled hosts compares any IP label in the IP options portion of the packet against the accreditation range of the network interface. If no IP option is specified, the default label assigned to the sending host is compared to the accreditation range on the network interface through which the packet is going. Because the "write up read-down" MAC rule is enforced even on communications between unlabeled hosts, the default label of the sending host must be dominated by the default label of the destination host. In practice, two way communications would be impossible unless both unlabeled hosts shared a default label.

Each gateway maintains a list of routes to all destinations. Standard Solaris routing metrics allow routes to be chosen based on the shortest path to the destination. Extensions in Trusted Solaris 2.5.1 and later compatible releases enable trusted routing based on the shortest path to the destination that also satisfies security requirements. IP security options in a packet allow IP labels to be available for accreditation range checks on intermediate routers.

Trusted routing depends on all gateways recognizing extended RIP, the Routing Information Protocol. Therefore, trusted routing is only possible in an Intranet whose gateways are all known to use RIP, because routing in the Internet is done using other protocols.

Some sites using trusted routing need to enable communications with Trusted Solaris hosts that are on the other side of a cloud of unlabeled hosts when communications must go through one or more routers that do not understand labels. At these sites, the Security Administrator role needs to set up tunneling. (The terms cloud and tunneling are defined under "Setting Up Tunneling".)

Choosing Routers

Because routes must be carefully chosen in the Trusted Solaris environment, the Security Administrator role needs to understand the security characteristics of all routers through which sensitive information is passing.

For the highest degree of trust, routes should be set up with Trusted Solaris computers as routers. If other types of routers are used, keep in mind that the Trusted Solaris security features are not always available on those routers, and without administrative action packets can be routed through routers without MAC security protection.

CIPSO and RIPSO routers drop packets when they do not find the right type of information in the IP options section of the packet. For example, a CIPSO router drops a packet if it does not find a matching CIPSO label or a matching DOI in the packet's IP options section. Other types of routers not running Trusted Solaris software do not drop packets when they find labels they do not understand in the IP options section; they just pass the packets along. Be aware of these considerations when setting up communications between hosts, and make sure that packets are routed through the appropriate types of routers.

To support trusted routing, the Trusted Solaris routing tables are extended to include security information along with the metric for the number of hops to the destination, as described below.

Specifying the SRI

The set of security attributes necessary for trusted routing is called the SRI (for security routing information). The SRI always includes a minimum and a maximum label to establish the route's accreditation range:

As described on the route(1M) man page, the SRI can also incorporate other security attributes. The SRI is obtained from one of two possible sources:

Emetric

The emetric (Extended Metric) consists of both the standard routing metric and the SRI. The emetric is stored in each route's entry in the routing table. The routing software selects the shortest path that satisfies the security requirements by comparing emetrics. Alternately, the emetric can be entered manually for static routes using the route(1M). (See "Routing Table" for how routes are manually defined.)

If dynamic routing is used, the routing daemon, in.routed broadcasts a special type of security-enhanced response packet advertising the known routes.

Several routes through multiple gateways may exist between a sending and receiving host, and the emetric for each route may be different.

Routing Table

The routing table in the kernel of each host contains routes. Each entry in the routing table provides a route to a particular destination:

Destination 

(a specific host or network) 

First hop gateway 

(first gateway in the route) 

Interface of gateway 

The routing software tries to find a route to the destination host in the route tables. When the host is not explicitly named, the routing software looks for an entry for the (sub)network where the host resides. When neither the host nor the network where the host resides is defined, the host sends the packet to a default gateway, if one has been defined. Multiple default gateways can be defined, and each is treated equally. A pointer keeps track of which default gateway has been used most recently, and the next one in the list is used for the next routing.

Routing table entries are created either of the following two ways:

With a small network, it is feasible to set up routes manually, and to manually make changes to the routing table when conditions change. For example, many sites have a single gateway through which all communications go to the outside world. In these cases, the single gateway can be statically defined as the default on each host on the network. Manually configuring and maintaining static routes is less feasible with large networks.

Extended RIP

Xerox Routing Information Protocol (RIP) version is extended in the Trusted Solaris environment to supply security attributes along with a route's metric when the router advertises the route. The extended RIP is compatible only within an Intranet whose gateways all recognize RIP, because routing in the Internet is done using other protocols.

Determining Dynamic or Static Routing

The following figure shows how the presence or absence of certain files and programs on a Trusted Solaris host that is not a gateway determines whether static or dynamic routing is done.

Figure 7-2 How a Host Determines Which Type of Routing to Do

Graphic

Enabling a Single-Label Gateway to Forward Packets at Multiple Labels

A single-label host (specified with a host type of Unlabeled or RIPSO) must be assigned a default label in its template. A minimum and a maximum label in the unlabeled host's template define an accreditation range that can be used for routing. Specifying the accreditation range enables a single-label gateway to be able to forward packets that it would not otherwise be allowed to receive based on its default label alone.

The trusted network software uses the accreditation range specified for a single-label gateway to decide which packets can be sent through that gateway. The packet being forwarded by the unlabeled gateway must be within the gateway's accreditation range.