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