HP OpenVMS Systems Documentation

Phase IV DLM circuits of type PERMANENT are replaced by routing circuits of type x25 permanent in DECnet Phase V. The circuit's data link entity characteristic is set to X25 access.

The circuit's template characteristic is set to the name of the X25 Protocol DTE PVC that will be used by this routing circuit.

Table H-13 shows the parameter mapping rules.

For example:

NCP> set circuit x25-perm usage permanent network mynet -
_ dte 123456789 channel 9
NCP> set circuit x25-perm maximum data 256 maximum window 7
NCP> set circuit x25-perm state on owner executor

ncl> create x25 protocol dte dsv-0 pvc x25-perm channel 9,packet size 256, -
_ncl> window size 7
ncl> create routing circuit x25-perm type x25 permanent
ncl> set    routing circuit x25-perm template x25-perm
ncl> enable routing circuit x25-perm

Phase IV user PVCs are equivalent to a pvc subordinate entity belonging to an x25 protocol dte entity. Table H-14 shows the parameter mapping rules.

For example:

NCP> set circuit x25-perm usage permanent network mynet -
_ dte 123456789 channel 9
NCP> set circuit x25-perm maximum data 256 maximum window 7
NCP> set circuit x25-perm state on

ncl> create x25 protocol dte dsv-0 pvc x25-perm channel 9,packet size 256, -
_ncl> window size 7

The basic mechanism for security is the same in both DECnet Phase IV and Phase V.

• Each incoming call acquires a set of rights identifiers based on the address of the remote DTE from which the call was received.
• Each user (or user process) has a set of rights identifiers acquired from the OpenVMS rights database.
• Each outgoing call to a multihost system acquires a set of rights identifiers based on the identity of the Access system's node.

Rights identifiers are then used to determine the level of access allowed to a particular VAX P.S.I. object (for example, a remote DTE). The access level is defined by access control lists (ACLs).

In DECnet Phase V, an ACL is always defined as an attribute of some network management entity. The syntax of an ACL is defined as a set of access control entries (ACEs). An ACE has the following format:

{Identifiers = {simplename1,simplename2,...},Access = access level}

where the simplename1,... strings are valid OpenVMS system rights identifiers.

H.3.1 VAX P.S.I. Security Specific Identifiers

In Phase IV, VAX P.S.I. security defines the following rights identifiers:

• PSI$X25_USER--- The rights identifier that must be granted to any user or process that is allowed to issue an IO$_ACCESS QIO
• PSI$DECLNAME--- The rights identifier that must be granted to any process that is allowed to declare itself as a network process by issuing an IO$_ACPCONTROLQIO

System managers can add other identifiers by the normal means.

DECnet Phase V X.25 security still uses the PSI$X25_USERand PSI$DECLNAMErights identifiers. Other identifiers are defined automatically by the configuration procedures. System managers can add other identifiers by the normal means.

H.3.2 VAX P.S.I. Security Access Actions

In Phase IV, VAX P.S.I. allows the following access actions:

• NONE --- No access to VAX P.S.I.
• INCOMING --- Allow incoming, non-reverse charge calls
• INCOMING+REVERSE_CHARGE --- Allow all incoming calls, including reverse charge calls
• OUTGOING --- Allow outgoing reverse charge calls
• OUTGOING+CHARGE --- Allow all outgoing calls, including reverse charge calls

DECnet Phase V uses the following access levels:

• NONE --- No access permitted.
• REMOTE CHARGE --- For outgoing calls, permit only those that use the reverse charge facility. For incoming calls, permit only those that do not use the reverse charge facility.
• ALL --- Permit all calls, whether or not they use the reverse charge facility. Since separate ACLs are used for incoming or outgoing calls, it is possible to specify different controls for each direction.

This section discusses database mapping.

H.3.3.1 The Remote DTE Rights Database

The Phase IV remote DTE rights database contains the rights identifiers associated with remote DTEs that want to make incoming calls to your system.

In DECnet Phase V, this information is distributed among the set of x25 access security dte class remote dte entities. Each x25 access security dte class remote dte entity has a rights identifiers attribute that is the set of rights identifiers possessed by a remote DTE. These identifiers are used by X.25 security when checking the ACL against an incoming call from the remote DTE.

For example:

ncl> create x25 access security dte class default remote dte MATCHALL -
_ncl> remote address prefix *
ncl> set x25 access security dte class default remote dte MATCHALL -
_ncl> rights identifiers (PSI$OPEN_SECURITY)

The Phase IV access node rights database contains the rights identifiers associated with Access nodes that are allowed to make outgoing calls through a multihost node.

In DECnet Phase V, this information is distributed among the set of x25 server security nodes entities at the multihost node. Each x25 server security nodes entity has a rights identifiers attribute that is the set of rights identifiers possessed by one or more Access system nodes, as defined by the nodes attribute. These identifiers are used by X.25 security when checking the ACL against an outgoing call from the Access node.

For example:

ncl> create x25 server security nodes clients
ncl> set x25 server security nodes clients nodes { ORG:.mynode }
ncl> set x25 server security nodes clients rights identifiers -
_ncl> { PSI$OPEN_SECURITY }

DECnet Phase V does not have an entity corresponding to the local DTE access control database used in Phase IV.

H.3.3.4 The Remote DTE Access Control Database

The Phase IV Remote DTE Access Control Database contains the ACLs that control the access actions associated with outgoing calls to remote DTEs.

In DECnet Phase V, this information is distributed among the set of x25 access security dte class remote dte entities. Each x25 access security dte class remote dte entity has an acl attribute that is the set of ACEs used by X.25 security when checking outgoing calls to the remote DTE.

For example:

ncl> create x25 access security dte class default remote dte MATCHALL -
_ncl> remote address prefix *
ncl> set x25 access security dte class default remote dte MATCHALL -
_ncl> acl ((identifier = ( * ), access = ALL))

The Phase IV Destination Access Control Database contains the ACLs that control the access actions associated with incoming calls to an X.25 destination.

In DECnet Phase V, this information is distributed among the set of x25 access security filter entities. Each x25 access security filter entity has an acl attribute that is the set of ACEs used by X.25 security when checking incoming calls for any filter that is using this X.25 access security filter.

For example:

ncl> create x25 access security filter DEFAULT
ncl> set x25 access security filter DEFAULT acl ((identifier =( * ), -
_ncl> access = ALL))

X.25 security for DECnet Phase V allows protection for the x25 protocol dte pvc and x25 protocol group entities.

Each x25 protocol dte pvc has an acl attribute that is the set of ACEs used by X.25 security when checking access to this PVC.

For example:

ncl> set x25 protocol dte dsv-0 pvc x25-perm acl { -
_ncl> (identifier =( * ), access = ALL) -
_ncl> }

Each bilateral closed user group (BCUG) has a remote dte attribute. This DTE address is associated with this entity for matching x25 access security dte class remote dte entities for both incoming and outgoing calls.

For example:

ncl> set x25 protocol group secret remote dte address 123456788

A graphical user interface is available for network management on OpenVMS systems. This interface is a Motif application that is located at SYS$SYSTEM:NET$MGMT.EXE.

I.1 Network Management Graphical User Interface (NET$MGMT)

The NET$MGMT utility provides a hierarchical graphical approach to the management of DECnet Phase V. The manageable components of DECnet Phase V (modules, entities and subentities) are represented in a tree-like structure below the icon that represents the node you are managing. The NET$MGMT utility provides an easy way to familiarize yourself with the organization of these manageable entities. If you choose to enable the displaying of NCL commands from the Default Actions pulldown, NET$MGMT can also help familiarize you with NCL syntax.

In addition to issuing NCL commands on your behalf, NET$MGMT can also perform task-oriented functions which involve many NCL commands or are complex in some way. The currently supported NET$MGMT tasks are:

• SHOW KNOWN LINKS
• SHOW KNOWN NODE COUNTERS
• CHECK TRANSPORTS

NET$MGMT also checks to ensure that the system display has the proper fonts available. The required font is -*-helvetica-Bold-R-Normal--12-120-75-75-P-70-ISO8859-1. If this font is not available, a message is displayed and NET$MGMT exits.

I.2 Rights Required to Run NET$MGMT

The same rights required to run NCL are also required to run NET$MGMT. The process invoking NET$MGMT must have at least one of the following rights enabled, or the process must possess BYPASS privilege:

• NET$EXAMINE --- Grants read access only
• NET$MANAGE --- Grants read and write access
• NET$SECURITY --- Grants the ability to modify default access control information for session control applications

The NET$MGMT utility is based on Motif. As such, it can be invoked using the same methods you use to invoke any other Motif application. Refer to the OpenVMS DECwindows Users Guide for information about how to run this application remotely. You can also run it locally by issuing the following command:

$ run sys$system:net$mgmt

The application will check for and load the Helvetica 12-point 75-pitch font. In the unlikely event that this font is not present, the application will exit with an error message.

Once you have started NET$MGMT, you can refer to the Help pull-down menus for more information.

I.4 Managing Other DECnet Phase V Nodes

You can use the NET$MGMT Set/Change Node option to manage a remote DECnet Phase V node. You have the option of providing explicit access control information. The remote account must have at least the NET$EXAMINE right in order to successfully switch management control to the remote node.

If you do not provide explicit access control information, your rights on the remote node will be determined by the rights granted to the account associated with the remote node's session control application CML. Generally, this account will be the CML$SERVER account which will have the NET$EXAMINE right. Therefore, you will usually need to supply explicit access control information to an account having NET$MANAGE right in order to make network configuration changes on a remote node.

When you wish to return to managing the local node, it is not necessary to provide explicit access control information. Simply choose the default "0" as the node name, and your previous rights will be restored.