top - download
⟦9c1dd17b2⟧ Wang Wps File
Length: 35919 (0x8c4f)
Types: Wang Wps File
Notes: LKSAA - PROPOSAL VOL II
Names: »4214A «
Derivation
└─⟦37660ca85⟧ Bits:30006030 8" Wang WCS floppy, CR 0386A
└─ ⟦this⟧ »4214A «
WangText
Issue 1.4
LKSAA - VOLUME II
SYS/84-04-24
Part 2
TECHNICAL PROPOSAL
Page
1 INCOMING MESSAGE PROCESSING ......................
337
1.1 MESSAGE RECEPTION ............................
338
1.1.1 Incoming Channels ........................
338
1.1.2 Message Reception Procedures .............
338
1.1.2.1 Message Reception ....................
338
1.1.2.2 Message Validation ...................
339
1.2 \REGISTRATION ................................
340
1.3 AUTOMATIC HEADER ANALYSIS ....................
340
1.3.1 Interpretation of the Message Format .....
341
1.3.2 Message Header Data ......................
341
1.3.2.1 Automatic Message Header Analysis ....
341
1.3.2.2 Message Correction ...................
341
1.3.2.3 Message Service Operator (MSO) .......
342
1.3.3 Message Header for "Fremdformat" .........
349
1.3.4 Service Messages .........................
349
1.4 AUTOMATIC MESSAGE PROCESSING .................
350
1.4.1 Validation of Channel-Serial-Number ......
350
1.4.2 Priority Levels ..........................
350
1.4.3 Start at Offline Decryption ..............
351
1.4.3.1 Analysis of Encryption Control Data ..
351
1.4.3.2 ZVA - Internal Decryption ............
351
1.4.3.3 ZVA - External Decryption ............
351
1.4.4 Messages for Off-Line Processing .........
351
1.5 TEST, TRANSFER AND CORRECTION ................
352
1.5.1 Prerequisites ............................
352
1.5.2 Message Validation .......................
352
1.5.3 Message Transfer and Correction ..........
356
1.5.3.1 Correction of Message in "Fremdformat
356
1.5.3.2 Correction of Decrypted Messages .....
357
1.5.4 Request for Repetition ...................
357
1.5.5 Cancellation of Correction ...............
358
1.6 SUBJECT CODING AND REDIRECTION ...............
358
1.6.1 General ..................................
358
1.6.2 Automatic Distribution ..................
360
1.6.3 Message Distribution Operator (MDCO) .....
360
1.6.4 Redirection ..............................
362
1.7 SECURITY PROCESSING ..........................
362
1.7.1 Security Classifications from Restricted
to Secret ................................
363
1.7.2 Top Secret Messages ......................
363
1.7.3 NATO - Classified Messages ...............
364a
1.7.4 Unauthorized Access to the System ........
364a
1.8 MESSAGE ACKNOWLEGEMENT .......................
364b
1.9 MESSAGE STORAGE AND RETRIEVAL ................
364b
1 I̲N̲C̲O̲M̲I̲N̲G̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
This section describes the automated message handling
capabilities, which supports exchange of information
via messages to and from AA over external networks
between AA and AV.
The system shall process two types of messages, which
are operational messages containing information pertinent
to AA and service messages dealing with communication
related activities.
The Message Handling System described is already in
existance developed for NATO by the contractor.
The system developed is very modular and flexible,
ensuring a low cost/risk in relation to further expansion.
The contractor intends to make use of the existing
software and append new facilities required for the
LKSAA System.
As examples of the provided message handling functions
the following diagrams represent the basic message
flow:
- incoming operational message (Fig. 1.3-1)
- incoming service message (Fig. 1.3-2)
- outgoing operational message (Fig. 1.3-3)
- outgining service message (Fig. 1.3-4)
The symbolism of these diagrams is summarized and described
as below, in detailed in the following sections.
An example on the basic flow of an incoming message
is:
I̲n̲c̲o̲m̲i̲n̲g̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲
(See Figure 1.3-1)
1. Reception error detected.
Supervisor Report.
2. Incoming message for Analysis
3. Analysis errors detected.
Message Correction.
4. Reentering after correction.
5. Analysis OK.
Flash message received.
6. Send Flash Acknowledge service message.
7. Distribute message.
8. Incoming Message Distribution.
1.1 M̲E̲S̲S̲A̲G̲E̲ ̲R̲E̲C̲E̲P̲T̲I̲O̲N̲
1.1.1 I̲n̲c̲o̲m̲i̲n̲g̲ ̲C̲h̲a̲n̲n̲e̲l̲s̲
The ZVA receives incoming messages from the following
channels:
- Leased lines (Standverbindungen)
- Dial-up lines, such as:
- Telex (Telex)
- Teletext (Teletex)
- Public Telephone Network
(Offenliches Fernsprechernetz)
- Radio Lines
- Papertape reader for the following messages:
- Off-line connections
- Papertapes for emergency input
- Papertapes for external encrypted messages.
Furthermore the system is designed for receiption of
messages to be received from high-speed data networks
using the X.25 protocol. Handling of this and other
protocols can be implemented as an option.
1.1.2 M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
1.1.2.1 M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲
The messages will be received as a stream of characters
from the low-speed telegraph channels and for high
speed channels (if optional applicable later) as a
stream of blocks. Data received on ITA2 code will be
converted to ITA5 code.
Off-line encrypted data in ITA2 code will not be converted
to ITA5. Data on Teletex Code can be converted to ITA5
or ITA2 if these data is to be presented at a terminal;
which is unable to handle the Teletex code. The conversion
tables shall be defined after guidlines from AA.The
reception process handles the spooling of these streams
and turns them into discrete messages, and files each
message in its "as-received form" with an attached
unique message identifier. This process will detect
certain channel and message error conditions.
The reception procesing is carried out by the Incoming
Transport depicted at Figure 1.3-3 to 1.3-4.
For messages received on papertape the ZVA will check
if the message is externally encrypted and this is
to be decrypted before it is read again by the system.
Control information for reread of each message will
be stored on the system.
1.1.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
Any incoming stream of characters will be continuously
monitored for:
- Start of Message Indicators
(such as ZCZC)
- End of Message Indicators
(such as NNNN or LLLL)
- Who are you? (WRU)
- Missing flow of characters of more than a defined
span of time
- Bell Signals
- Specific criteria for no EOTF detected in general,
for dial-up lines and for papertape as specified
in "lastenheft".
The channel and message error conditions detected are:
- Too long line
- Oversized Message
- No EOTF detected before start of next message.
- Missing BT
- Halted Message
- Preempted Message (ZPH detected)
- Transmission Identifier discontinuity.
During the assembling into a complete message, the
PAGE indicators may be stripped (if any) facilitating
internal presentation using other paging principles.
For encrypted messages a reidentification will take
place after synchronization of cryptos.
1.2 R̲E̲G̲I̲S̲T̲R̲A̲T̲I̲O̲N̲
The system has the capability to store all incoming
and outgoing messages to allow users to subsequently
retrieve, them as required.
Messages are stored on on-line. Messages are kept on-line
for at least 14 days at a maximum specified traffic
load.
Messages are stored together with a number of retrieval
parameters which are Internal System Number , time
of occurance, release Data Time Group, originating
AV, message identification, channel identification,
station serial number, subject indicator code, message
identification and user code.
1.3 A̲U̲T̲O̲M̲A̲T̲I̲C̲ ̲H̲E̲A̲D̲E̲R̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲
Next the message will undertake an analysis to check
that the incoming message has been fully received in
accordance with the AA construction rules and/or the
ACP127/COREU/WUI construction rules.
(Ref. Analysis Figure 1.3-1 and 1.3-2).
The functions of the Analysis are:
- message type determination
(service or operational message)
- format line detection and validation
- internal format conversion
- detection of messages with a Pilot
- detection of a readdressed message
- detection of Service Messages for internal handling
(i.e. Channel Check, Channel Test and Flash Acknowledge.)
- consistency checks (i.e. Security-check)
The detailed procedures for AA- Analysis have been
laid down in "Lastenheft - Teil 3- Anhang 1".
The detailed procedures for ACP127- analysis has been
laid down into the bidders baseline document CPS/230/ICD/0003.
1.3.1 I̲n̲t̲e̲r̲p̲r̲e̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲t̲h̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲o̲r̲m̲a̲t̲
The allowed message format will be specified per reception
channel.
By means of a Supervisor Procedure the actual valid
message format for a specific channel can be specified
as one of the following:
- AA- Format
- ACP127 - Format
- Data Message (non-formatted message - "Fremdformat")
Message, which are not recognized to conform the allowed
message format will be distributed for the Message
Service Operator(s) (MSO) for message correction. The
MSO can after correction of the message for an allowed
format rerun the message i.e. the message will be sent
for repeated automatic message analysis. If the analysis
is OK, the message will then automatically be distributed.
1.3.2 M̲e̲s̲s̲a̲g̲e̲ ̲H̲e̲a̲d̲e̲r̲ ̲D̲a̲t̲a̲
1.3.2.1 A̲u̲t̲o̲m̲a̲t̲i̲c̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲e̲a̲d̲e̲r̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
The message analysis will after recognition of the
message format analyse the message header data to allow
further processing.
For messages in "Fremdformat" the Header Data will
be set up on AA-Format if possible.
1.3.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲
Errors, inconsistencies, garbles, channel faults and
messages which cannot be analyzed or distributed are
detected by the system and sent to the communication
personnel.
Two categories of operators are defined:
One is the Message Service Operator (MSO), who process
non valid, erroneous and garbled messages; the other
is the Message Distribution Operator (MDCO) who handles
distribution of all messages for which there is no
automatic distribution.
1.3.2.3 M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲O̲p̲e̲r̲a̲t̲o̲r̲ ̲(̲M̲S̲O̲)̲
Messages are sent to garble correction because of different
reasons. Main errors will be displayed in the system
line, while detected analysis errors will be indicated
in the left hand margin area by error codes. The message
which needs garble correction will be presented on
the VDU screen in 3 parts:
- HEADING
- TEXT
- ENDING
See VDU screen layout figure 1.3.2.3-1
Fields within the format are unprotected and the user
will be able to modify and correct fields presented.
Main errors could occur due to one of the following
reasons:
- TOO LONG LINE
- NO EOTF
- MISSING BT (after the text)
- OVERSIZED MESSAGE
- HALTED MESSAGE
- UNIDENTIFIED MESSAGE
- FL 14 CORRECTIONS
- ANALYSIS ERRORS
The main error displayed in the response line will
give an idea about what and where in the message format
the problem occurs.
Another mode of the Message Service Functions is the
Inspections:
- TI Inspection
- Pilot Inspection
- Flash Inspection
When the function is inspection, the Message Service
Opertor cannot alter anything because all fields are
protected.
TI inspection is when some descripancy or discontinuity
are found in the Transmission Identifier during Reception
Procedures. If the Transmission Serial Number as an
example is equal to the one of the last received message,
the now received message might be a duplicate.- The
MSO has to be the judge of this and reenter the message
for continued analysis in case the message is not a
duplicate. The same is the case for Pilot inspection,
where the pilot is detected during analysis.
Since the message sent for garble correction and the
message possibly returned from garble correction for
continued analysis is formatted into two different
message ̲view, it will not be necessary for the Message
Servicer to mark sections not be be re ̲analyzed; he
can then freely edit the header and text and add his
comment.
Messages for garble correction or inspection can be
inhibitied by a simple command in order to avoid message
distribution.
Figure 1.3-1
Figure 1.3-2
Figure 1.3-3
Figure 1.3-4
Figure 1.3.2.3-1
1.3.3 M̲e̲s̲s̲a̲g̲e̲ ̲H̲e̲a̲d̲e̲r̲ ̲f̲o̲r̲ ̲"̲F̲r̲e̲m̲d̲f̲o̲r̲m̲a̲t̲"̲
Messages in "Fremdformat" will be distributed to the
Message Service Operator (MSO). The MSO may add a Message
Header on AA- Format and keep the total and unchanged
original message as message body.
If the MSO is able to correct the message, header data
will only be contained in the message header in AA-format.
1.3.4 S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Message flow diagrams figure 1.3-1 and 1.3-4 represent
the principle processing of an incoming service message.
Three types of Service Messages are detected furing
format ̲analysis:
- ASM (simplified Service Message)
- Abbreviated Plaindress Service Message
- Plaindress Service Message.
The ASM is characterized not having the text enveloped
with BT's, the Abbreviated Plaindress does not contain
originator action addresses, information addresses
and exempt addresses.
All types of service messages are accepted as incoming
messages and can be prepared and transmitted from supervisory
positions.
Both incoming and outgoing service messages are logged.
Should an operational message be subject for message
correction it is possible to flag the message as Service
Message by appending the SIC = SVC in the respective
format line.
1.4 A̲U̲T̲O̲M̲A̲T̲I̲C̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
1.4.1 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲C̲h̲a̲n̲n̲e̲l̲-̲S̲e̲r̲i̲a̲l̲-̲N̲u̲m̲b̲e̲r̲
The Channel-Serial-Number (if applicable) is validated
for a consistency (continuity) in number series and
possible missing numbers are requested.
1.4.2 P̲r̲i̲o̲r̲i̲t̲y̲ ̲L̲e̲v̲e̲l̲s̲
The Message Switching System is designed for a multilevel
priority system.
The priority levels are:
- Flash
- Immediate
- Priority
- Routine
Handling of Flash Messages can be made available as
an option.
The desinged flow of an incoming flash message is shown
in figure 1.3-1.
The received flash message not containing the operating
signal ZGC is automatically acknowledged by returning
a -flash Acknowledge ASM to the originator.
In addition the message can be sent to a message service
operator for inspection with the notation FLASH INSPECTION.
During distribution of the flash message to as specified
user position, the ZZ ̲field of the status line will
be incremented as a discrete warning to the users,
that a flash message has arrived to this queue.
For the reception of messages on papertape a Flash
Priority (level 4) will be allocated if "Hochste Proritat"
is activated.
1.4.3 S̲t̲a̲r̲t̲ ̲a̲t̲ ̲O̲f̲f̲l̲i̲n̲e̲ ̲D̲e̲c̲r̲y̲p̲t̲i̲o̲n̲
1.4.3.1 A̲n̲a̲l̲y̲s̲i̲s̲ ̲o̲f̲ ̲E̲n̲c̲r̲y̲p̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲D̲a̲t̲a̲
By analysis of the Encryption Control Data (Schlusselkenndaten)
the ZVA determines whether the message shall be automatic
decrypted internal in the ZVA or external decrypted.
Input and storage of the means for encryption is determined
by station number, roll number and encryption-key-number.
1.4.3.2 Z̲V̲A̲ ̲-̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲ ̲D̲e̲c̲r̲y̲p̲t̲i̲o̲n̲
For automatic ZVA- internal decryption the necessary
data is transferred to the Crypto-System immediately
after analysis of the Encryption Control Data and the
Crypto- System transfers the key to the Crypto-Device.
After errorless reception of the key the data transfer
is initiated by the ZVA. The decrypted message is then
analysed for header data.
If the message cannot be decrypted without errors the
message is distributed to the message service operator
for a special message correction procedure.
1.4.3.3 Z̲V̲A̲ ̲-̲ ̲E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲e̲c̲r̲y̲p̲t̲i̲o̲n̲
Messages for ZVA external decryption is distributed
to the Message Distribution Operator (MDCO), which
initiates a punch-out on papertape for an off-line
crypto device. Message status is stored on the ZVA,
so message processing can be resumed after the decrypted
message is read again on papertape. After this stage
the message is analysed for header data. For Top Secret
Messages, resumed processing in ZVA is not allowed.
1.4.4 M̲e̲s̲s̲a̲g̲e̲s̲ ̲f̲o̲r̲ ̲O̲f̲f̲-̲L̲i̲n̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Messages for off-line processing will be distributed
to the Message Distribution Operator, which will initiate
a punch-out of the original message. In addition an
instruction for off-line processing will be printed
as well as logged by the ZVA and the processing of
the message on the ZVA is then finished.
1.5 T̲E̲S̲T̲,̲ ̲T̲R̲A̲N̲S̲F̲E̲R̲ ̲A̲N̲D̲ ̲C̲O̲R̲R̲E̲C̲T̲I̲O̲N̲
1.5.1 P̲r̲e̲r̲e̲q̲u̲i̲s̲i̲t̲e̲s̲
Messages received by the Incoming Transport Package
are stored and queued for further processing according
to the recognized priorities. Off-line decrypted messages
are stored on the original received format as well
as the decrypted message format.
A catalogue for all incoming messages can be retrieved
and listed according to message priorities.
1.5.2 M̲e̲s̲s̲a̲g̲e̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
Messages in plain text will, if not distributed to
external processing be validated for syntax and semantics.
Erroneous messages will be distributed for the Message
Service Operator position for garble correction. After
correction the message will be automatically reanalysed
and if no errors are left the message will be transferred
to automatic distribution. In case some errors are
left, the message will again be distributed for garble
correction. The Supervisor can set and reset prespecified
parameters in order to force certain messages to the
Message Service Operator.
On the Message Service Operator VDU status of the different
queues, one for each priority level, will continuously
be displayed and updated on a separate screen split.
Function keys will be available for transaction procession
such as enter of corrected data, cancel of message,
present next message, display corretive explanation
for errors, print message. A complete catalogue of
incoming messages can be displayed for status overview.
The available functions can be selected from a menu
and each function is executed in a man-machine dialogue.
Example on a menu is shown on figure 1.5.2-1 and an
example on a screen layout is shown on figure 1.5.2-2.
The screen is a partitioned in three splits: a command
and status split, a system split and a user split.
For the VDU's specified for the Message Service Operator(s)
capabilities can dynamically be assigned by the Supervisor
for execution of various functions such as: Incoming
Message Assistance, Outgoing Message Assistance, Mesage
Distribition Assistance, Service Message Preparation,
Retrieval for Local Use, Retrieval for Rerun, Retrieval
for Redistribution, Retrieval for Readdressal and Retrieval
for Deletion.
Figure 1.5.2-1
Figure 1.5.1-2
1.5.3 M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲ ̲a̲n̲d̲ ̲C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲
As mentioned in section 1.5.2 message header correction
will be handled from the Message Service Operator position(s).
Queue Status showing the number of incoming messages
on the different priority levels will continuously
be displayed on the upper screen split. Furthermore
an incoming message catalogue can be displayed on the
user screen split.
After successful validation and correction of the Message
Header Data, the message will be transferred for the
designated user terminal queue.
The associated user capability for message presentation
and message text correction may be assigned to either
the same VDU or another VDU according to the terminal
profile. This may be altered dynamically by a Supervisor
Command.
To ease correction of messages the validation procedure
will display error codes on the margin and highlight
the errorous fields in inverse video. By activating
a function key the explanation for the actual error
code will be displayed in the response lime.
When a message is corrected satisfactoryly, a release
decision format will be presented on the screen for
a release yes/no decision. After release, the message
will be automatically distributed according to the
specified addresses. Release capabilities will be
assigned to the VDU terminal and the user according
to the profiles set in the system tables. These profiles
can be dynamically changed by the Supervisor.
1.5.3.1 C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲i̲n̲ ̲"̲F̲r̲e̲m̲d̲f̲o̲r̲m̲a̲t̲"̲
Messages in "Fremdformat" (Data Message) is distributed
to the Message Service Operator (MSO) for append/correction
the header data necessary for further message distribution.
The MSO may decide either to correct the message to
be suitable for distribution or to add a AA-Format
Message Header. If the latter is selected, the MSO
will be prompted to fill in the necessary parameters
for the AA-Format Message Header.
After MSO assistance the message is analysed again
for proper header data.
Message received in ACP 127 - Format will, if the ACP
127 - analyssis results in a message header without
errors, automatically generate an AA-Format Header
if possible. If this is not possible, the message will
be distributed to the MSO for message assistance and
correction.
1.5.3.2 C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲D̲e̲c̲r̲y̲p̲t̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
In case of non-successful decryption of messages the
Message Service Operator (MSO) shall be able to correct
the message as follows:
1. Renewed decryption of the original and unchanged
message.
2. Change of Crypto Control Data ("Schlusselkenndaten")
3. Correction of all characters.
4. Characterwise shifting of the starting point for
decryption.
This will be accomplished by four separate commands
for the MSO using the functions of the formatted screen.
All commands can be executed by the MSO (and repeated)
whenever appropriate, as long as the capabilities are
assigned. These may be changed by the Supervisor for
reasons of flexibility and security.
1.5.4 R̲e̲q̲u̲e̲s̲t̲ ̲f̲o̲r̲ ̲R̲e̲p̲e̲t̲i̲t̲i̲o̲n̲
The Message Service Operator (MSO) has functions available
for preparation of Service Messages as mentioned earlier.
Service Messages can be used for requesting the sender
to repeat the message. This facility allows the MSO
to prepare any service message to any sender or addressee
remote or local. Priority level of Service Messages
may be selected as appropriate, but default is, that
the Service Message priority is one level higher than
the corresponding message.
Service Messages can be prepared as Full Text Messages
or abbreviated Service Messages for convenience. In
addition standarised and predefined messages can be
stored for semiautomatic preparation i.e., controlled
by the terminal user. Service Messages can, if specified,
be sent as encrypted messages.
Even if a message is subject to repetition the MSO
may decide to distribute the received message as it
is, if this is possible. This decision will generate
a log record containing amongst other log data the
message status.
1.5.5 C̲a̲n̲c̲e̲l̲l̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲
Correction of a message may be cancelled at any point
of processing by activating the allocated function
key for cancel.
For messages forced to correction by a specified parameter,
correction can be stopped at any point using a control
key.
1.6 S̲U̲B̲J̲E̲C̲T̲ ̲C̲O̲D̲I̲N̲G̲ ̲A̲N̲D̲ ̲R̲E̲D̲I̲R̲E̲C̲T̲I̲O̲N̲
1.6.1 G̲e̲n̲e̲r̲a̲l̲
Incoming messages in plain text are queued by the Traffic
Handling Package (THP) to the Message Distribution
Package (MDP) for internal distribution. The determination
of distribution is based on the following information.
- The sections (AE's) to which distribution shall
be performed at this site
- A variable number of indicator codes (SICs) (if
wanted)
- Number of copies
The SIC combination will point out a standard distribtuion
list. From these lists MDP will generate a nominal
distribution list.
After generation of the nominal distribution list,
the incoming messages are either distributed to the
addressees in the list or queued for support by the
Message Distribution Operator (MDCO).
Messages will be distributed according to priority
and security levels.
The latter ensures, that a message to which the message
security level is higher than the level specified for
in the terminal and user profile cannot be displayed
at that position.
In addition to the addresses identified on the standard
distribution list stored in tables on the ZVA an "exempt"
facility can be provided optionally to allow for exemption
from this list.
Addressees can be addressed as "working" addressees
and "info" addressees. The latter is not meant to process
the received messages, but only to receive these for
information purposes.
Addresses marked with the keywork "ZEN" will be ignored
i.e. they have already received the message via other
channels.
All messages are logged before distribution to the
users.
Messages received outside the defined normal working
hours will be distributed to the defined duty position.
The duty position can, when the capabilties for message
distribution are allocated by the Supervisor, distribute
the messages to the appropriate position or receive
the messages for processing.
1.6.2 A̲u̲t̲o̲m̲a̲t̲i̲c̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
The Message Distribution Package (MDP) will validate
the messages according to the defined distribution
criterias and check the distribution lists for valid
entries. For Messages validated satifactory the necessary
distribution data will automatically be retrieved from
the tables in the ZVA and the message will be distributed
to the relevant terminals and working positions.
The tables containing distribution lists and other
data for distribution can be updated dynamicaly from
the Supervisor VDU's by means of a man-machine dialogue.
If a message cannot be automatic distributed to the
user positions due to missing information, it will
be sent to the Message Distribution Operator (MDCO)
for assistance.
Furthermore messages can be forced to the MDCO e.g.
due to security or special handling instructions. Parameters
for forcing messages to the MDCO can be either general
or instructions on the individual message level.
1.6.3 M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲O̲p̲e̲r̲a̲t̲o̲r̲ ̲(̲M̲D̲C̲O̲)̲
Messages are sent for "incoming message assistance"
because of the following reasons:
- Missing or garbled SICs
- Detection of special SICs
- Detection of Internal Handling Instructions
- Detection of Special Handling Instruction of categories
Crypto Security
- Detection of more than one Special Handling Instruction
The annotation line will inform the MDCO why the message
is sent for assistance. Refer to figure 1.6.3-1 showing
the VDU screen layout.
The MDCO has the capability to specify for which terminal
(user sections, SCD's) a distribution shall take place.
Figure 1.6.3-1
1.6.4 R̲e̲d̲i̲r̲e̲c̲t̲i̲o̲n̲
The ZVA provides a built-in relay function for automatic
redirection of messages from the ZVA to another address
in a network.
Messages for redirection can be stored and displayed
or printed if wanted.
1.7 S̲E̲C̲U̲R̲I̲T̲Y̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
The offered LKSAA System is based on an already existing
system developed by the Contractor for NATO to meet
very strict security requirements.
Processing af all messages are monitored by specified
procedures, (Trusted Computer Base), which enforces
the security policy upon all software modules performing
data manipulation.
The Trusted Computer Base will enforce proper authentification
of the terminal and the user on the terminal and require
reauthentication after security relevant events as
specified by the Security Administrator.
Security attributes are implemented by means of a user
security profile and a user group identifier and security
profiles for terminals, devices and channels.
Users identify themselves by means of a physical key
and a user name plans a password.
The security mecanisms are described in detail in section
2.7.
Below specific requirement to security processing will
be addressed.
The following AA Classfications will be handled:
- Offen
- Verschluesselt
- VS - Nur fuer den Dienstgebrauch
- VS - Vertraulich - amtlich geheimhalten
- Geheim - amtlich geheimhalten
- Streng Geheim - amtlich geheimhalten
Different types of spelling and typing wil be handled
as specified in the RFP (Lastenheft)
The following NATO - classifications will be handled:
- Clear
- NATO Unclassified
- NATO Restricted
- NATO Confidential
- NATO Secret (plus ATOMAL)
- COSMIC Top Secret (Plus ATOMAL)
1.7.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲l̲a̲s̲s̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲f̲r̲o̲m̲ ̲R̲e̲s̲t̲r̲i̲c̲t̲e̲d̲ ̲t̲o̲ ̲S̲e̲c̲r̲e̲t̲
The screen of a terminal is devided into two parts;
a security split and a format split. The security split
can only be accessed by security monitors and contains
a security attribute line. The classification and security
log number will be contained on top and bottom of all
displayed and/or printed messages.
All messages will be logged in a security log containing
Security Log Number, Date-Time-gGoup, System Number,
Distribution and User Identification, the Message Header
untill and including the Security Classification.
1.7.2 T̲o̲p̲ ̲S̲e̲c̲r̲e̲t̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
For decrypted messages of the classification Top Secret
a special notice (as specified in the RFP (Lastenheft)
will be displayed and the message will n̲o̲t̲ be shown.
The message on papertape will be logged according to
the procedures.
For Top Secret Messages buffer area and disc area will
be erased after processing.
1.7.3 N̲A̲T̲O̲ ̲-̲ ̲C̲l̲a̲s̲s̲i̲f̲i̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Messages containing the NATO- classifications can be
processed by the ZVA - System.
By means of a system parameter controlled by the Supervisor,
processing of certain non national classifications
can be prevented or directed to dedicated devices.
NATO classified messages to be processed by the ZVA
will be handled analog to the corresponding national
classifications but the original NATO classification
will be kept.
1.7.4 U̲n̲a̲u̲t̲h̲o̲r̲i̲z̲e̲d̲ ̲A̲c̲c̲e̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲S̲y̲s̲t̲e̲m̲
The LKSAA System includes mechanism to prevent unauthorized
access on terminals as well as on channels. Terminals
are monitored by the Terminal Monitoring and Control
Package (TEMCO), Devices are monitored by the Device
Monitoring and Control Package (DEMCO) and channels
are monitored by the Channel Monitoring and Control
Package (CEMCO). These monitors are part of the secure
operatoring system. The principles described in Part
1, section 2.7.2.2 concerning Terminal Security does
also apply for devices and channels. A channel is assigned
a security profile and messages to be sent via an external
channel are controlled against the security profile.
In case of non-recognized control information in the
message header, a message will be sent to the message
service operator.
All messages contain channel serial numbers, which
are controlled for a possible change in the sequence.
It can be proposed as an option to add an encrypted
check sum to all transactions, which gives the possibility
to immediately detect if a transaction has been altered
(e.g. if unauthorized equipment has been hooked on
the line).
In case it is attempted to jam the system, the system
supervisor can use the commands for close or disconnect
of lines and/or cancellation of queues. In additional
threshold detection mechanism will activate a warning
to the system supervisor. If the supervisor does not
react on this warning and the critical threshold level
is exceeded, the system can automatically disconnect
the line, if this option is selected.
1.8 M̲E̲S̲S̲A̲G̲E̲ ̲A̲C̲K̲N̲O̲W̲L̲E̲G̲E̲M̲E̲N̲T̲
When a message is received correctly and data for distribution
can be recognised, an acknowledgement is generated
automatically by the ZVA but not logged as a message.
The routing for acknowledgements as well as correlation
of acknowledgements can be controlled according to
specified parameters.
The layout for message acknowledgement can be controlled
by parameters specified by the supervisor.
1.9 M̲E̲S̲S̲A̲G̲E̲ ̲S̲T̲O̲R̲A̲G̲E̲ ̲A̲N̲D̲ ̲R̲E̲T̲R̲I̲E̲V̲A̲L̲
The system has the capability to store all incoming
and outgoing messages to allow users to subsequently
retrieve, them as required.
Messages are stored in the format as received and in
the format, which is validated and subject to mesage
distribution.
Messages are stored on on-line as well as off-line
devices. Messages are kept one-line up to 30 days after
which they are dumped to off-line devices.
Messages are stored together with a number of retrieval
parameters which are Internal System Number, Time of
Occurance (System Date and Time), Release Date Time
Group, Originating AV, message identification, channel
identification, station serial number, subject indicator
code, message identification and user code.
The mentioned parameters not applicable to the RFP,
can be provided as an option.
A Retrieval can take place by one or more of the above
mentioned parameter. In addition to the above parameters,
a time range can be specified for which mesages shall
be retrieved.
If more than one message meets the criteria, a retrieval
catalogue is presented, which refers to messages fitting
the key. The user can based on the catalogue display
select the one to be chosen.
Below are presented some examples of retrieval formats,
one available to the user, the other available to the
system supervisor. (figures 1.9-1 and 1.9-2).
Figure 1.9-1
Figure 1.9-2
