22. IP Security Option

IPSO Security

IPSO is an option included in the header of a datagram that specifies the datagram's level of security. This option is a label. A system can check for the existence of an IPSO label in an incoming datagram and determine whether the datagram matches its specific security requirements. Likewise, a system can screen outbound datagrams based on their labels.

For an IPSO-supported system, if a datagram does not pass a label test, the system considers it out of range and rejects (discards) it. The system then sends an ICMP error message (if enabled) describing the condition to the datagram's originator. The system manager must decide:

The consequences of using IPSO security

IPSO has a far reaching effect on all network applications running over IP.

The IPSO security option the system requires

The system manager can decide to implement the Basic Security Option or Extended Security Option.

The security level (or levels) for incoming or outgoing datagrams

Top Secret, Secret, Confidential, or Unclassified.

The protection authority (or combination of authorities) for incoming or outgoing datagrams

GENSER, SIOP-ESI, SCI, NSA, or DOE.

How to set IPSO on a system-wide and individual port (line) basis.

 

What to do with unlabeled datagrams

The system manager can either reject such datagrams or implicitly label them so that they pass IPSO screening tests.

How to set security on ICMP error messages generated by out-of-range datagrams

In some cases, you must set IPSO on these messages so that the system does not reject them; in other cases, the system manager may want these messages to be "invisible."

 

Consequences

IPSO is for physically secure TCP/IP networks run by trusted system managers with the highest security clearance. You should segregate IPSO networks from non-IPSO networks. IPSO-protected datagrams should never enter a non-IPSO network.

IPSO affects everything in a TCP/IP-based network. For example, TELNET connections are impossible if receiving systems reject IPSO-labeled datagrams. This also affects FTP, NFS, FINGER, Line Printer Services, RSH, RCP, RLOGIN, among others.

IPSO also affects other protocols on which these applications may depend, such as the DNS, Kerberos, NTP, TIMED, RIP, and RAP. If a host cannot communicate with a DNS server, for example, all host information required to run an application becomes unavailable. In such cases, system managers must set all possible DNS servers with the same IPSO security.

Basic and Extended Security Options

IPSO incorporates a Basic Security Option and an Extended Security Option. Each IPSO-labeled datagram has in its IP header authorization information related to these options.

The Basic Security Option is well-documented, standardized, and includes the security levels and protection authorities described in the next subsection.

RFC 1108 minimally mentions the Extended Security Options, but they need more definition. Security managers can use extended options as custom, site-specific protocols they do not want to reveal. These options occupy extra space in the IP header after the basic option. You can only use them together with an existing basic option. TCPware supports the extended options in allowing or disallowing extended options in datagrams.

Security Levels and Protection Authorities

An IPSO security label consists of a classification level and a protection authority. The classification levels appear in the below table with their hexadecimal values. The protection authorities appear in the following table with their hex values and points of contact.

Security level

Has hexadecimal value

Top_Secret

%X3D

Secret

%X5A

Confidential

%X96

Unclassified

%XAB

 

Protection authority

Has hex value

With point of contact

GENSER

%X80

Designated Approving Authority per DOD 5200.28

SIOP-ESI

%X40

DoD Joint Chiefs of Staff

SCI

%X20

Director of Central Intelligence

NSA

%X10

National Security Agency

DOE

%X08

Department of Energy

Labeling as Opposed to Screening a Datagram

There are two distinctions in IPSO:

·         Labeling an outgoing datagram

·         Screening datagrams

Some datagrams already have IPSO labels when they reach your system, for example, by socket calls or other labeling methods. You can label "raw" datagrams by adding an implicit transmit label onto the datagram using a TCPware command. (You can also redefine already labeled datagrams in the same way.)

Screening a datagram involves checking whether to allow the labeled datagram in or out. You use TCPware IPSO commands for this purpose. You can screen on a system-wide and line-by-line basis, as discussed in the next section.

System and Line Basis Protection

You can set IP Security Options on a system-wide and line-by-line basis.

·         The system requirements determine whether a datagram can enter or leave the system.

·         The line requirements determine whether a datagram can enter or leave a specific port (line) on the system.

Datagrams destined for your system or the ones your system generates undergo system level IPSO checks. Datagrams just passing through (being forwarded) undergo only line checks on the port they use. All datagrams undergo line checks.

You can restrict types of security to certain lines or make security requirements for forwarded datagrams different than for datagrams destined for the system. You can also use system requirements to cover lines not specifically set. To be effective, system requirements should be supersets of all individual line requirements.

Both system and line settings consist of incoming and outgoing requirements. The below example shows how to use a SET IPSO /SYSTEM command so that both incoming and outgoing requirements are for a security level of UNCLASSIFIED and a protection authority of NONE. These are the default settings if you do not specify a level or authority. (Note that the levels show up as ranges of values with the SHOW IPSO command.)

NETCU>SET IPSO /SYSTEM
NETCU>SHOW IPSO
Tcpware(R) for OpenVMS IPSO Configuration for System:

Label       Level                         Authorities
-----       -----                         -----------
In:         UNCLASSIFIED to UNCLASSIFIED  None
Out:        UNCLASSIFIED to UNCLASSIFIED  None

Implied
  Receive:  UNCLASSIFIED                  None
  Transmit: UNCLASSIFIED                  None
ICMP Error: UNCLASSIFIED                  None

To set the incoming and outgoing requirements separately, you could specify a command such as in the below example. The incoming label now requires an UNCLASSIFIED to SECRET level range on a system basis. All the other values remain the same.

NETCU>SET IPSO /SYSTEM /IN_LABEL=(LEVEL=(UNCLASSIFIED,SECRET))
NETCU>SHOW IPSO
Tcpware(R) for OpenVMS IPSO Configuration for System:

Label       Level                         Authorities
-----       -----                         -----------
In:         UNCLASSIFIED to SECRET        None
Out:        UNCLASSIFIED to UNCLASSIFIED  None

Implied
  Receive:  UNCLASSIFIED                  None
  Transmit: UNCLASSIFIED                  None
ICMP Error: UNCLASSIFIED                  None

If you want the line to accept just SECRET incoming datagrams, you could use a command such as in the below example. Again, only the incoming line requirement changes.

NETCU>SET IPSO /LINE=SVA-0 /IN_LABEL=(LEVEL=SECRET
NETCU>SET IPSO /LINE=SVA-0 /RECEIVE_IMPLICIT_LABEL=(LEVEL=SECRET)
NETCU>SHOW IPSO
Tcpware(R) for OpenVMS IPSO Configuration for line SVA-0:

Label       Level                         Authorities
-----       -----                         -----------
In:         SECRET to SECRET              None
Out:        UNCLASSIFIED to UNCLASSIFIED  None

Implied
  Receive:  SECRET                        None
  Transmit: UNCLASSIFIED                  None
ICMP Error: UNCLASSIFIED                  None

You can also use SET NOIPSO to disable IPSO.

Unlabeled Datagrams

The example in the previous section also shows what to do about unlabeled datagrams. The             /RECEIVE_IMPLICIT_LABEL qualifier used on the second line ensures that the system accepts unlabeled received datagrams as if they were SECRET (see the Implied... Receive: output). If the received implicit label had been left at UNCLASSIFIED, unlabeled datagrams would not pass the incoming test.

Frequently, systems do not allow implicit labeling, to prevent unlabeled datagrams from entering (or passing through) a system.

Sample Implementation

The below example shows a sample IPSO implementation.

Host A routes a datagram through host B to get to its destination, host C. The datagram has the label "SECRET SCI." This label passes A's outgoing system and port checks, as indicated. Since B only routes the datagram, it performs only port checks on the datagram. B then forwards the datagram to C. The datagram passes C's incoming port and system checks and successfully reaches the user or application.

The implementation assumes a cooperative network scenario. In this scenario, system managers on hosts A, B, and C communicate with each other on setting security options. Even intermediate hosts (like B) need to be aware of the nature of the secure traffic routed through. Otherwise, such a system could lose datagrams.

Other configurations may not set up system checks, and therefore, not perform them. If an IPSO check fails, the datagram is out of range and the system sends an ICMP error message back to the originator. However, the ICMP message itself must have the appropriate label so that it can pass the system and port checks for an outgoing datagram.

Commands

You add IPSO labels to datagrams, and set system and line requirements for IPSO screening using commands in TCPware's Network Control Utility (NETCU). These commands are:

·         SET IPSO

·         SHOW IPSO

To invoke NETCU, enter:

$ NETCU

and enter the series of IPSO commands you need to configure the system or lines at the NETCU> prompts.

See Chapter 2, NETCU Commands, in the NETCU Command Reference for detailed descriptions of these commands.

You can also include each command in your TCPWARE:IPSO_SETUP.COM file.

The basic format of the NETCU command that sets IPSO screening is:

SET IPSO {/SYSTEM | /LINE} /LABEL-TYPE=(LEVEL=level, AUTHORITY=auth)

/SYSTEM or /LINE=line

is the system-wide setting or the line number (such as SVA-0).

/LABEL-TYPE

is one of the following:

/LABEL - label for both received (incoming) and transmitted (outgoing) datagrams

/IN_LABEL - label for incoming datagrams only

/OUT_LABEL - label for outgoing datagrams only

level

is either a single security level (level), or a range (minimum and maximum) security level in the form (min-level, max-level). You can use either the name of the security level or its hexadecimal value as shown in IPSO Security Levels; for example, Top_Secret or %X3D.

 

In specifying the range of levels, the min-level must be lower on the list in IPSO Security Levels than the max-level.

auth

is either a single protection authority or a list of authorities in the form (auth1, auth2, ..., authn). You can use either the name of the authority or its hexadecimal value as shown in IPSO Protection Authorities; for example, GENSER or 0x80. Decimal and octal values are also acceptable.

 

Each authn can also be in the form "auth1+auth2+...+authn" (a combination of authorities strung together with plus signs and enclosed in quotes). An example is "GENSER+SCI" - this means that you can process only datagrams with the combination GENSER+SCI. Alternatively, you can use the site-specific name set up in the IPSO_AUTHORITIES. file; for example, ALPHA for "SCI+NSA". (See Site-Specific Authority Names.)

 

Suppose you want to set up line SVA-0 to accept all incoming or outgoing datagrams with a security level ranging from UNCLASSIFIED to SECRET. You also want the line to accept a protection authority of either GENSER or a combination of SCI+NSA. Perform the following command at the NETCU prompt:

NETCU>SET IPSO /LINE=SVA-0 -
_NETCU>/LABEL=(LEVEL=(UNCLASSIFIED,SECRET), -
_NETCU>AUTHORITY=(GENSER,"SCI+NSA"))

Adding an IPSO Label 

Add explicit IPSO labels to transmitted datagrams using the /TRANSMIT_IMPLICIT_LABEL qualifier together with the /ADD qualifier, as in:

NETCU>SET IPSO /LINE=SVA-0 -
_NETCU>/TRANSMIT_IMPLICIT_LABEL=(LEVEL=SECRET, AUTHORITY=DOE, ADD)
NETCU>SHOW IPSO
%TCPWARE_NETCU-I-NOIPSODATA, no IPSO being processed on System

TCPware(R) for OpenVMS IPSO Configuration for line SVA-0:
Label       Level                         Authorities
-----       -----                         -----------
In:         UNCLASSIFIED to UNCLASSIFIED  None
Out:        SECRET to SECRET              DOE
Implied
  Receive:  UNCLASSIFIED                  None
  Transmit: SECRET                        DOE
ICMP Error: SECRET                        DOE
Adding implied label to transmitted datagrams

This imposes the SECRET level and DOE authority on all unlabeled datagrams going out on line SVA-0. The ADD keyword actually adds the IPSO header information to the datagrams.

Note from the SHOW IPSO output that the outgoing label and ICMP error requirements must already have been set to match the explicitly added label:

NETCU>SET IPSO /LINE=SVA-0 /OUT=(LEVEL=SECRET,AUTH=DOE)
NETCU>SET IPSO /LINE=SVA-0 /ERROR=(LEVEL=SECRET,AUTH=DOE)
Otherwise, the following error messages would appear:
%TCPWARE_NETCU-W-OUTOFRANGE, implied outgoing authority out-of-range for SVA-0
%TCPWARE_NETCU-W-OUTOFRANGE, implied outgoing level out-of-range for SVA-0
%TCPWARE_NETCU-W-OUTOFRANGE, error authority out-of-range for SVA-0
%TCPWARE_NETCU-W-OUTOFRANGE, error level out-of-range for SVA-0

Accepting Datagrams Regardless of Authority

You can have the system accept datagrams regardless of their authority label by using the AUTHORITY=ANY value. In the following example, the host processes any datagram with a SECRET level and ignores the authority setting (note that the implicit labels and ICMP error were already set to match the line requirements):

NETCU>SET IPSO /LINE=SVA-0 /LABEL=(LEVEL=SECRET, AUTHORITY=ANY)
NETCU>SHOW IPSO
%TCPWARE_NETCU-I-NOIPSODATA, no IPSO being processed on System
TCPware(R) for OpenVMS IPSO Configuration for line SVA-0:
Label       Level               Authorities
-----       -----               -----------
In:         SECRET to SECRET    None
Out:        SECRET to SECRET    None

Implied
  Receive:  SECRET              None
  Transmit: SECRET              None
ICMP Error: SECRET              None
Ignoring authority field on received datagrams
Ignoring authority field on transmitted datagrams

Applying Implicit Labels

You can have the system associate labels with incoming or outgoing datagrams not having labels. Use the /RECEIVE_IMPLICIT_LABEL or /TRANSMIT_IMPLICIT_LABEL qualifier (without the ADD keyword), as in:

NETCU>SET IPSO /LINE=SVA-0 -
_NETCU>/RECEIVE_IMPLICIT_LABEL=(LEVEL=SECRET, AUTHORITY=GENSER)
%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming authority out-of-range for SVA-0
%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming level out-of-range for SVA-0
NETCU>SHOW IPSO
%TCPWARE_NETCU-I-NOIPSODATA, no IPSO being processed on System
TCPware(R) for OpenVMS IPSO Configuration for line SVA-0:

Label        Level                          Authorities
-----        -----                          -----------
In:          UNCLASSIFIED to UNCLASSIFIED   None
Out:         UNCLASSIFIED to UNCLASSIFIED   None

Implied
  Receive:   SECRET                         GENSER
  Transmit:  UNCLASSIFIED                   None
ICMP Error:  UNCLASSIFIED                   None

%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming authority out-of-range for SVA-0
%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming level out-of-range for SVA-0

In the example, the system manager associated the SECRET GENSER option with any unlabeled incoming datagrams on line SVA-0. The system does not actually add the label to the datagram header. (The example also shows the error messages resulting from not setting up matching requirements for the incoming and outgoing labels.) Additional keywords can accomplish the following:

REQUIRED

Require an IPSO label and do not use an implicit one

NOREQUIRED

Do not require an IPSO label and use an implicit one

NONE

Set an implicit label with an UNCLASSIFIED level and null authority

 

Datagrams with Extended Security Options

You can have the system accept or transmit datagrams containing extended security options. TCPware enables this by default. To explicitly enable extended options, use the /EXTENDED_ALLOWED qualifier for incoming or outgoing datagrams, or both, as in:

NETCU>SET IPSO /LINE=SVA-0 /EXTENDED_ALLOWED

You can selectively disallow security options using the NOIN and NOOUT keywords (as in              /EXTENDED_ALLOWED=NOIN), or disallow them more generally using                                         /NOEXTENDED_ALLOWED. The latter produces the following lines at the bottom of a SHOW IPSO output:

Extended IPSO options on received datagrams disallowed
Extended IPSO options on transmitted datagrams disallowed

Stripping Datagrams of Options

You can have the system strip any Basic Security Options present in an outgoing datagram. This is useful for routers and forwarding datagrams on which you do not want to impose security restrictions. Use the /STRIP qualifier, as in:

NETCU>SET IPSO /LINE=SVA-0 /STRIP

This produces SHOW IPSO output that includes the line Stripping IPSO option on transmitted datagrams. /NOSTRIP is the default.

Be careful stripping datagrams of basic options. The datagrams could get lost as a result of further checks that require these options.

Setting IP Security Options First in the Datagram Header

Some security systems require that the security options appear first in datagram headers. If this is the case, use the /FIRST qualifier, as in:

NETCU>SET IPSO /LINE=SVA-0 /FIRST

This produces SHOW IPSO output that includes the line Placing IPSO option first on transmitted datagrams. /NOFIRST is the default.

Enabling ICMP Errors

If a datagram arrives out of range, the originator should receive a returned ICMP message to indicate the error. For this to happen, the returned message itself must have the proper security label. Enable this using the /ERROR_LABEL qualifier, as in:

NETCU>SET IPSO /LINE=SVA-0 -
_NETCU>/ERROR_LABEL=(LEVEL=SECRET, AUTHORITY=GENSER)

Define only a single level and authority for an error label. The level and authority should always be a subset of the level and authority defined for the outgoing label. For example, the following SHOW IPSO output shows a valid port setting for the requirement above:

TCPware(R) for OpenVMS IPSO Configuration for line SVA-0:

Label       Level                         Authorities
-----       -----                         -----------
In:         UNCLASSIFIED to UNCLASSIFIED  None
Out:        UNCLASSIFIED to SECRET        GENSER

Implied
  Receive:  UNCLASSIFIED                  None
  Transmit: SECRET                        GENSER
ICMP Error: SECRET                        GENSER

To disallow ICMP message handling, use /ERROR_LABEL=NONE. This resets the ICMP error setting to UNCLASSIFIED NONE. However, disallowing ICMP message handling can be risky.

 

Note: Always set the system requirements first. This sets each line identically. Then make isolated changes to the line requirements.

 

Automatic Startup

The STARTNET procedure uses the TCPWARE:ROUTING.COM file to automatically set security options at TCPware startup.

The file can contain the NETCU commands used to set IPSO options, as discussed earlier. Any commands in this file can refer to the IPSO_AUTHORITIES. file for authority definitions. (See Site-Specific Authority Names.) The below example shows sample content of the ROUTING.COM file.

Sample ROUTING.COM file:

$ NETCU
SET IPSO /SYSTEM /LABEL=(LEVEL=(UNCLASSIFIED,SECRET),AUTH=(DOE,SCI))
SET IPSO /SYSTEM /RECEIVE_IMPLICIT=(LEVEL=UNCLASSIFIED,AUTH=DOE)
SET IPSO /SYSTEM /TRANSMIT_IMPLICIT=(LEVEL=SECRET,AUTH=DOE)
SET IPSO /SYSTEM /ERROR_LABEL=(LEVEL=SECRET,AUTH=DOE)
SET IPSO /LINE=SVA-0 /OUT_LABEL=(LEVEL=SECRET,AUTH=DOE)-
/IN_LABEL=(LEVEL=(UNCLASSIFIED,SECRET),AUTH=(DOE,SCI,"DOE+SCI"))
EXIT

The commands produce the following result:

NETCU>SHOW IPSO

TCPware(R) for OpenVMS IPSO Configuration for System:

Label       Level                     Authorities
-----       -----                     -----------
In:         UNCLASSIFIED to SECRET    DOE
                                      SCI
Out:        UNCLASSIFIED to SECRET    DOE
                                      SCI

Implied
  Receive:  UNCLASSIFIED              DOE
  Transmit: SECRET                    DOE
ICMP Error: SECRET                    DOE


TCPware(R) for OpenVMS IPSO Configuration for line SVA-0:

Label       Level                     Authorities
-----       -----                     -----------
In:         UNCLASSIFIED to SECRET    DOE
                                      SCI
                                      (DOE+SCI)
Out:        SECRET to SECRET          DOE

Implied
  Receive:  UNCLASSIFIED              DOE
  Transmit: SECRET                    DOE
ICMP Error: SECRET                    DOE

Site-Specific Authority Names

The TCPWARE:IPSO_AUTHORITIES. file (include the dot at the end) contains a table translating bit masks to protection authorities. Edit this file to create site-specific authorities (aliases) or authority combinations you can associate with an alias name. You can create an alias authority name that is the name of the system a certain combination of authorities frequently protect. For example, you can associate the name ALPHA, the system that frequently needs to have SCI and NSA (inclusive) authority protection, with the authority combination SCI+NSA.

To do this, enter the value ALPHA in the file along with the logically OR'd bit mask values of the combined pre-defined authorities, as indicated in the below example. In the case of ALPHA, the hexadecimal value 0x30 comes from 0x20 + 0x10. In the case of DELTA, the hexadecimal value 0xC0 comes from 0x80 + 0x40 (GENSER+SIOP-ESI).

!GENSER    0x80
!SIOP-ESI  0x40
!SCI       0x20
!NSA       0x10
!DOE       0x08
!
!SITE-SPECIFIC:
ALPHA      0x30     !SCI+NSA
BETA       0x50     !SIOP-ESI+NSA
DELTA      0xC0     !GENSER+SIOP-ESI

As indicated in the above example, the predefined authorities (GENSER to DOE) are in the IPSO_AUTHORITIES. file for reference purposes only and are commented out using an exclamation point (!). You must also comment out the description after each site-specific entry.

 

Caution! Do not delete the IPSO_AUTHORITIES. file.

 

 

This setup allows you to specify a site-specific authority in an IPSO command such as:

NETCU>SET IPSO /LINE=SVA-0 /LABEL=(LEVEL=(UNCLASSIFIED,SECRET),-
_NETCU>AUTHORITY=(GENSER,ALPHA))

which, if combined with other appropriate settings, produces the SHOW IPSO output:

NETCU>SHOW IPSO
%TCPWARE_NETCU-I-NOIPSODATA, no IPSO being processed on System
TCPware(R) for OpenVMS IPSO Configuration for line SVA-0:
Label       Level                    Authorities
-----       -----                    -----------
In:         UNCLASSIFIED to SECRET   GENSER
                                     ALPHA(NSA+SCI)
Out:        UNCLASSIFIED to SECRET   GENSER
                                     ALPHA(NSA+SCI)

Implied
  Receive:  UNCLASSIFIED             GENSER
  Transmit: UNCLASSIFIED             GENSER
ICMP Error: UNCLASSIFIED             GENSER

Full SHOW IPSO Output

With the /FULL qualifier, the SHOW IPSO command produces the usual output along with additional counter information for incoming and outgoing datagrams. This information includes the number of datagrams that:

·         Contain Basic Security Options

·         Were delivered or transmitted

·         Contain Extended Security Options

·         Use implicit labeling

·         Were rejected as out-of-range

·         Were rejected due to containing extended options

·         Lack a required basic option.

Typical output is:

NETCU>SHOW IPSO /FULL

TCPware(R) for OpenVMS IPSO Configuration for System:
Label       Level                         Authorities
-----       -----                         -----------
In:         UNCLASSIFIED to UNCLASSIFIED  None
Out:        UNCLASSIFIED to UNCLASSIFIED  None

Implied
  Receive:  UNCLASSIFIED                  None
  Transmit: UNCLASSIFIED                  None
ICMP Error: UNCLASSIFIED                  None

          Incoming datagrams screened by IPSO
              0 contained a BSO
            559 were delivered to receivers
              0 contained extended options
            559 used implicit labelling
              0 were rejected as out-of-range
              0 were rejected due to containing ESO
              0 lacked a required BSO

          Outgoing datagrams screened by IPSO
              0 contained a BSO
            100 were successfully transmitted
              0 contained extended options
              0 used implicit labelling
              0 were rejected as out-of-range
              0 were rejected due to containing ESO
              0 lacked a required BSO

Troubleshooting

Out-of-range datagram error messages appear both as warnings after SET IPSO and in SHOW IPSO output. Here are a few conditions that could produce out-of-range error messages:

·         A label was set without an associated implicit label:

NETCU>SET IPSO /SYS /IN=(LEVEL=(CONFIDENTIAL,SECRET),AUTH=DOE)

%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming authority out-of-range for System

%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming level out-of-range for System

NETCU>SHOW IPSO

TCPware(R) for OpenVMS IPSO Configuration for System:

Label       Level                         Authorities

-----       -----                         -----------

In:         CONFIDENTIAL to SECRET        DOE

Out:        UNCLASSIFIED to UNCLASSIFIED  None

 

Implied

  Receive:  UNCLASSIFIED                  None

  Transmit: UNCLASSIFIED                  None

ICMP Error: UNCLASSIFIED                  None

 

%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming authority out-of-range for System

%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming level out-of-range for System

·         An implicit label is not a subset of the default label setting:

NETCU>SET IPSO /SYS /REC=(LEVEL=CONFIDENTIAL,AUTH=DOE)

%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming authority out-of-range for System

%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming level out-of-range for System

NETCU>SHOW IPSO

TCPware(R) for OpenVMS IPSO Configuration for System:

 

Label       Level                         Authorities

-----       -----                         -----------

In:         UNCLASSIFIED to UNCLASSIFIED  None

Out:        UNCLASSIFIED to UNCLASSIFIED  None

Implied

  Receive:  CONFIDENTIAL                  DOE

  Transmit: UNCLASSIFIED                  None

ICMP Error: UNCLASSIFIED                  None

 

%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming authority out-of-range for System

%TCPWARE_NETCU-W-OUTOFRANGE, implied incoming level out-of-range for System

·         An ICMP error label does not match the outgoing label setting:

NETCU>SET IPSO /SYS /ERROR=(LEVEL=CONFIDENTIAL,AUTH=DOE)

%TCPWARE_NETCU-W-OUTOFRANGE, error authority out-of-range for System

%TCPWARE_NETCU-W-OUTOFRANGE, error level out-of-range for System

NETCU>SHOW IPSO

TCPware(R) for OpenVMS IPSO Configuration for System:

 

Label       Level                         Authorities

-----       -----                         -----------

In:         UNCLASSIFIED to CONFIDENTIAL  SCI

Out:        SECRET to TOP_SECRET          SCI

 

Implied

  Receive:  CONFIDENTIAL                  SCI

  Transmit: SECRET                        SCI

ICMP Error: CONFIDENTIAL                  DOE

 

%TCPWARE_NETCU-W-OUTOFRANGE, error authority out-of-range for System

%TCPWARE_NETCU-W-OUTOFRANGE, error level out-of-range for System