Solaris Trusted Extensions Administrator's Procedures

Administration of Labeled IPsec

Solaris Trusted Extensions systems can protect labeled network packets with IPsec. The IPsec packets can be sent with explicit or implicit Trusted Extensions labels. Labels are sent explicitly by using CIPSO IP options and implicitly by using labeled IPsec security associations (SAs). Also, IPsec encrypted packets with different implicit labels can be tunneled across an unlabeled network.

For general IPsec concepts and configuration procedures, see Part III, IP Security, in System Administration Guide: IP Services. For Trusted Extensions modifications to IPsec procedures, see Configuring Labeled IPsec (Task Map).

Labels for IPsec-Protected Exchanges

All communications on Trusted Extensions systems, including IPsec-protected communications, must satisfy security label accreditation checks. The checks are described in Trusted Extensions Accreditation Checks.

The labels on IPsec packets that must pass these checks are the inner label, the wire label, and the key management label:

Label Extensions for IPsec Security Associations

IPsec label extensions are used on Trusted Extensions systems to associate a label with the traffic that is carried inside a security association (SA). By default, IPsec does not use label extensions and therefore ignores labels. All traffic between two systems flows through a single SA, regardless of the Trusted Extensions label.

Label extensions enable you to do the following:

You can specify whether to use label extensions automatically through IKE as described in Label Extensions for IKE, or manually through the ipseckey command. For details on the label extensions features, see the ipseckey(1M) man page.

When using label extensions, SA selection for outbound traffic includes the inner sensitivity label as part of the match. The security label of inbound traffic is defined by the security label of received packet's SA.

Label Extensions for IKE

IKE on Trusted Extensions systems supports the negotiation of labels for SAs with label-aware peers.

You can control this mechanism by using the following keywords in the /etc/inet/ike/config file:

For more information, see the ike.config(4) man page.

Labels and Accreditation in Tunnel Mode IPsec

When application data packets are protected by IPsec in tunnel mode, the packets contain multiple IP headers.

The graphic shows an outer IP header followed by ESP
or AH, then an inner IP header, a TCP header, then data.

The IKE protocol's IP header contains the same source and destination address pair as the application data packet's outer IP header.

The graphic shows an outer IP header followed by a UDP
header, and finally the IKE key management protocol.

Trusted Extensions uses the inner IP header addresses for inner label accreditation checks. Trusted Extensions performs wire and key management label checks by using the outer IP header addresses. For information about the accreditation checks, see Trusted Extensions Accreditation Checks.

Confidentiality and Integrity Protections With Label Extensions

The following table explains how IPsec confidentiality and integrity protections apply to the security label with various configurations of label extensions.

Security Association 



Without label extensions 

Label is visible in the CIPSO IP option. 

Message label in the CIPSO IP option is covered by AH, not by ESP. See Note. 

With label extensions 

A CIPSO IP option is visible, but represents the wire label, which might be different from the inner message label. 

Label integrity is implicitly covered by the existence of a label-specific SA. 

On-the-wire CIPSO IP option is covered by AH. See Note. 

With label extensions and CIPSO IP option suppressed 

Message label is not visible. 

Label integrity is implicitly covered by existence of a label-specific SA. 

Note –

You cannot use IPsec AH integrity protections to protect the CIPSO IP option if CIPSO-aware routers might strip or add the CIPSO IP option as a message travels through the network. Any modification to the CIPSO IP option will invalidate the message and cause a packet that is protected by AH to be dropped at the destination.