Network Working Group J. Dempsey
INTERNET-DRAFT C. Feil
N. Lewis
Paramax Systems Corporation
June 1, 1992
SECURITY INFORMATION TRANSFER PROTOCOL (SITP)
Status of this Memo
This memo defines the Security Information Transfer Protocol
(SITP) used to send and receive security information between sys-
tems in a TCP/IP network. An initiator can use SITP to set re-
mote audit and other management parameters, and to request audit
data, discretionary access control lists, and other data from a
responder. The responder handles the request and sets parameters
or returns the requested data. SITP has been adopted by the
Trusted System Interoperability Group as the protocol of choice
for audit management. This document supersedes the July 1991 In-
ternet Draft of the same name. Distribution of this memo is un-
limited.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use In-
ternet Drafts as reference material or to cite them other than as
a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Paramax Systems Corporation Expiration: December 1, 1992
[Page 1]
Internet Draft SITP June 1, 1992
Table of Contents
1. INTRODUCTION 3
1.1 Network Architectures 3
1.2 Storage of Data 4
1.3 Transfer of Data 5
2. SITP SERVICES 5
2.1 SITP Get Service 6
2.2 SITP Set Service 10
2.3 SITP Data Service 13
2.4 SITP Cancel Service 17
3. SITP AND AUDITING 20
3.1 Common Audit Formats 20
3.2 Audit Collection Versus Audit Control 20
3.3 Protection of Audit Data 20
3.4 SITP Versus CMOT and SNMP For Audit Collection 20
4. REFERENCES 22
5. ACKNOWLEDGEMENTS 22
6. AUTHORS' ADDRESS 22
Paramax Systems Corporation Expiration: December 1, 1992
[Page 2]
Internet Draft SITP June 1, 1992
1. INTRODUCTION
This document defines the Security Information Transfer Protocol
(SITP), a simple transaction protocol suitable for transferring
security information between systems in a TCP/IP network. An in-
itiator can use SITP to request data from, or set management
parameters at, a responder. The responder handles the request
and sets or returns the resulting data. Both the amount of time
required to generate the response and the amount of data returned
can be very large. These are the main reasons for a unique pro-
tocol to support this type of service.
The initial motivation to write this document was to define a
standard protocol for collecting audit data in a network environ-
ment (see Section 3). However, a need developed for a protocol
to perform more complete audit management, and to transfer other
security information, such as discretionary access control data
and general security administration data. To accommodate these
needs, SITP was generalized to include the functionality of a
simple transaction protocol.
1.1 Network Architectures
Using a minimal number of services, SITP can support various net-
work architectures, such as manager/agent, client/server, and
peer-to-peer. The format of the data transferred by SITP is
application-specific. Therefore, for an application using SITP,
a separate document or RFC is needed to define the syntax and se-
mantics of the transferred data.
Figure 1 illustrates the hierarchical structure that typically
exists between Managers and Agents. Using SITP, a Manager can
set parameters on and receive data from an Agent, and an Agent
can send data to a Manager. An Agent can run on an end system
(e.g., a host or workstation) or an intermediate system (e.g.,
bridge or router).
An example of an application using the manager/agent architecture
is an audit application, where the data being transferred may be
audit or security alert data. For audit applications, an Agent
running on an end system will generally collect both host and
network-specific audit data. An Agent running on an intermediate
system will generally collect network-specific audit data only.
Audit data may be requested from an Agent by the Manager or, if
the system on which the Agent is running does not contain suffi-
cient local storage, the audit data may be sent unsolicited to
the Manager using SITP. A manager can also set audit collection
parameters on an Agent.
A Manager/Agent system supports the full functionality of both a
Manager and an Agent on a single end system. The Manager-portion
collects audit data from its Agents. The mechanism through which
the data collected by the Manager-portion is passed to the
Agent-portion within a single end system is not part of this do-
cument.
Paramax Systems Corporation Expiration: December 1, 1992
[Page 3]
Internet Draft SITP June 1, 1992
Figure 1 also illustrates an xManager serving two xAgents. The
dashed lines between the xManager and xAgents indicate that a
protocol other than SITP is being used for this interaction. The
Agent, which co-resides with the xManager, uses SITP to communi-
cate to its Manager.
Manager
/ | | \
M-A A A xM-A
/ | \ : :
A A A xA xA
Legend:
M - Manager
A - Agent (e.g., Workstation, Host, Network Device)
xM - xManager
xA - xAgent
Figure 1. Hierarchical Structure of Managers and Agents
Figure 2 illustrates the hierarchical structure that typically
exists between Clients and Servers. Data flow in the
Client/Server architecture is roughly the reverse of that in the
Manager/Agent architecture. Here, a Client requests data from a
Server. One application using the Client/Server architecture is
an access control application, where the information being
transferred may be host-host or user-host discretionary access
control data. The Clients request this access control data from
the Server.
Server
/ | | \
S-C C C xS-C
/ | \ : :
C C C xC xC
Legend:
S - Server
C - Client (e.g., Workstation, Host, Network Device)
xS - xServer
xC - xClient
Figure 2. Hierarchical Structure of Clients and Servers
The remainder of this document describes SITP functionality in
terms of the Manager/Agent architecture, but keep in mind it is
suitable for other architectures as well.
1.2 Storage of Data
SITP supports an abstract, virtual view of how the data is stored
on an end system. This view includes independent data items,
tables, and fields within tables. This view does not force any
specific implementation aspects for supporting the actual data
storage on a real system.
Paramax Systems Corporation Expiration: December 1, 1992
[Page 4]
Internet Draft SITP June 1, 1992
1.3 Transfer of Data
SITP supports two basic modes of operation: push and pull. Un-
solicited data sent from an Agent to a Manager is said to be
pushed. For example, security alert data that indicates a spe-
cial event on an Agent should be pushed to the Manager. Addi-
tionally, collected data that cannot be stored locally (e.g., au-
dit data on a network device) may be pushed to the Manager. In
general, data is pushed to a Manager for analysis and long term
storage to a backup medium such as tape.
One or two TCP connections may be used to push data. The first
TCP connection, initiated by the Agent, is used to send the data.
The second TCP connection, initiated by the Manager, is used to
send a response indicating the data has been safely stored on the
Manager. At its discretion, a Manager may optionally use the
same TCP connection the data was received on to send its
response.
Data sent from an Agent to a Manager in response to a request is
said to be pulled. One or two TCP connections are used to pull
data. The first TCP connection, initiated by the Manager, is
used to send the data request. The second TCP connection, ini-
tiated by the Agent, is used to send the requested data. At its
discretion, an Agent may optionally use the same TCP connection
the request was received on to send the data. Typically, the
amount of time required by the Agent to gather the requested data
will be large enough that a separate TCP connection should be
used for the response. All responses to a request must be re-
turned on a single TCP connection.
The quantity of data pushed or pulled from an Agent to a Manager
may be reduced through the use of filters. A filter is a means
for selecting only the data which is of interest to the Manager.
Some examples of filters for audit data are start and stop times
and user ids. Filters reduce the processing and storage require-
ments of data at the Manager, and the amount of data transferred
on the network.
SITP uses standard TCP services to provide a reliable transfer of
data at the Transport Layer. Port number 182 has been reserved
with the Internet Assigned Numbers Authority for use by audit
collection applications. Other applications require their own
port numbers.
2. SITP SERVICES
There are four SITP services:
1. SITP Get
2. SITP Set
3. SITP Data
4. SITP Cancel
Paramax Systems Corporation Expiration: December 1, 1992
[Page 5]
Internet Draft SITP June 1, 1992
Table 1 highlights the mandatory (M) and optional (O) service
primitives implemented by Managers, Agents, Servers, Clients, and
Peer-to-Peer entities.
Service Primitives Manager Agent Server Client Peer
------------------ ------- ----- ------ ------ ----
SITP-GET.request M O O M M
SITP-GET.response O M M O M
SITP-SET.request O O O O O
SITP-SET.response O M O O M
SITP-DATA.request O M M O M
SITP-DATA.response M O O M M
SITP-CANCEL.request M O O M M
SITP-CANCEL.response O M M O M
Table 1. SITP Services
2.1 SITP Get Service
The SITP Get Service is used by a Manager to request data from an
Agent. After the request is made, the Manager initiates a close
waiting to the underlying TCP connection. The Agent usually
closes the first connection and then processes the request. When
the Agent is ready to send the data, a second TCP connection is
opened by the Agent. The Agent, at its option, may choose to ig-
nore the Managers request to close the first TCP connection and
instead use the same connection to transfer the data. Once the
Agent is ready to send the data and the TCP connection is esta-
blished, the data is sent from the Agent to the Manager and the
TCP connection closed. Figure 3 illustrates the SITP Get Ser-
vice. The SITP Get Service is defined by the SITP Get
Request/Indication and SITP Get Response/Confirmation service
primitives. One or more Get Response PDUs may be required to
respond to a single Get Request. These Get Responses should use
the same TCP connection.
Manager Agent
| |
SITP-GET.request -->|------>|--> SITP-GET.indication
| |
SITP-GET.confirmation <--|<------|<-- SITP-GET.response
SITP-GET.confirmation <--|<------|<-- SITP-GET.response
SITP-GET.confirmation <--|<------|<-- SITP-GET.response
| |
Figure 3. SITP Get Service
2.1.1 SITP Get Request PDU
The following format defines an SITP Get Request Protocol Data
Unit (PDU):
Paramax Systems Corporation Expiration: December 1, 1992
[Page 6]
Internet Draft SITP June 1, 1992
Field #Octets Type Status
----- ------- ---- ------
Length 2 unsigned integer Mandatory
PDU Type Identifier 1 unsigned integer Mandatory
Application Identifier 1 unsigned integer Mandatory
Processing Qualifier 1 unsigned integer Mandatory
Data Format Identifier 1 unsigned integer Mandatory
Get Request Identifier 2 unsigned integer Mandatory
Field Count 2 unsigned integer Optional
Field Identifier 2 unsigned integer Optional
Field Length 2 unsigned integer Optional
Field Value Variable octet string Optional
2.1.1.1 Length
The Length field contains the total length of the SITP Get Re-
quest PDU (including the Length field) in octets. The maximum
size of a single SITP Get Request PDU is 65,535 octets.
2.1.1.2 PDU Type Identifier
A PDU Type Identifier of 1 uniquely identifies a SITP Get Request
PDU.
2.1.1.3 Application Identifier
The Application Identifier uniquely identifies the application.
Values for the Application Identifier are assigned by the Inter-
net Assigned Numbers Authority. Each Application Identifier is
associated with one well known TCP port number for receiving new
incoming connections.
2.1.1.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. In
general, the Processing Qualifier can specify the type of data to
be sent (e.g., host audit data, network audit data, or security
alert data), a priority level for processing the data (e.g., high
or normal), a time delay, or that the request should be forward-
ed. The semantics of how the Processing Qualifier is actually
used must be defined elsewhere in a separate document or RFC. If
this field is not used, the Processing Qualifier is set to zero
(0).
2.1.1.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of data
for each application. For example, if the Application Identifier
is Audit Application, a Data Format Identifier can be reserved
for audit data defined using Version 2 of the DNSIX Audit Format
[DIA90a-b]. Values for the Data Format Identifier are assigned
by the Internet Assigned Numbers Authority.
Paramax Systems Corporation Expiration: December 1, 1992
[Page 7]
Internet Draft SITP June 1, 1992
2.1.1.6 Get Request Identifier
The Get Request Identifier uniquely identifies an SITP Get Re-
quest PDU. One or more SITP Get Responses can be used to respond
to a SITP Get Request. A Get Request Identifier of zero (0) is
reserved by the SITP Cancel Service, and should not be used in an
SITP Get Request PDU.
2.1.1.7 Field Count
The Field Count specifies the number of fields appearing in this
SITP Get Request PDU. The specific semantics of the field values
depend on the application. A filter is one example of a field
value. If there are no fields, the Field Count field should not
be included in the SITP Get Request PDU. If there are fields,
the Field Identifier, Field Length, and Field Value fields appear
Field Count times, as follows:
Field Count (N),
Field Identifier 1,
Field Length 1,
Field Value 1,
Field Identifier 2,
Field Length 2,
Field Value 2,
...
Field Identifier N,
Field Length N, and
Field Value N.
2.1.1.8 Field Identifier
The Field Identifier specifies the data to extract. The syntax
and semantics of a Field Identifier value is dependent on the Ap-
plication Identifier (see Section 2.1.1.3) and Data Format Iden-
tifier (see Section 2.1.1.5). There can be up to 65,536 unique
field identifiers defined for a single Data Format Identifier.
The first field identifier may specify that the field value con-
tains the name of a table to use.
Field Identifiers can also be used by a Manager to specify Agents
being managed by another Manager. For example, if a Manager
makes a request to a Manager/Agent, a Field Identifier may indi-
cate that its Field Value contains a list of Agents from which
data is desired.
2.1.1.9 Field Length
The Field Length specifies the length of the field value in oc-
tets.
2.1.1.10 Field Value
The Field Value contains the value of the field. For example, an
audit application may want to extract data on users John, Nina,
Carl, and Ryan. In this instance, the field identifier can be
Paramax Systems Corporation Expiration: December 1, 1992
[Page 8]
Internet Draft SITP June 1, 1992
set to userid and the field value set to "john nina carl ryan".
2.1.2 SITP Get Response PDU
The following format defines an SITP Get Response PDU:
Field #Octets Type Status
----- ------- ---- ------
Length 2 unsigned integer Mandatory
PDU Type Identifier 1 unsigned integer Mandatory
Application Identifier 1 unsigned integer Mandatory
Processing Qualifier 1 unsigned integer Mandatory
Data Format Identifier 1 unsigned integer Mandatory
Get Request Identifier 2 unsigned integer Mandatory
Status 1 unsigned integer Mandatory
Data Variable octet string Optional
2.1.2.1 Length
The Length field contains the total length of the SITP Get
Response PDU (including the Length field) in octets. The maximum
size of a single SITP Get Response PDU is 65,535 octets.
2.1.2.2 PDU Type Identifier
The PDU Type Identifier of 2 uniquely identifies an SITP Get
Response PDU.
2.1.2.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 2.1.1.3.
2.1.2.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 2.1.1.4.
2.1.2.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 2.1.1.5.
2.1.2.6 Get Request Identifier
The Get Request Identifier contains the Get Request Identifier of
the SITP Get Request PDU that prompted this SITP Get Response.
2.1.2.7 Status
The Status field reflects the possible status values of the SITP
Get Response. The six defined values for the status field are:
Paramax Systems Corporation Expiration: December 1, 1992
[Page 9]
Internet Draft SITP June 1, 1992
Value Meaning
0 More Data Coming
1 No More Data
2 No Data Found
3 Field Identified Does Not Exist
4 Unable To Process Request Temporarily
5 Unable To Process Request Permanently
If more than one SITP Get Response is sent in response to a re-
quest, the status field will be set to zero (0) for all SITP Get
Responses, except the final one for which the status field will
be set to one (1). A status value of two (2) indicates that,
while the fields identified are valid, no data corresponds to the
specified fields or there is no data currently stored at the
Agent. A status value of three (3) indicates that the field
identified does not exist. A status value of four (4) indicates
that the Agent is temporarily not able to process the request.
The Manager determines when to retry. A status value of five (5)
indicates that the Agent is permanently unable to process the re-
quest for some reason and the Manager should not try the same re-
quest. When determining which status value to return, the lowest
number status value that applies should be used.
2.1.2.8 Data
The Data field contains the data being pulled. The format of the
data is defined by the Application Identifier (see Section
2.1.1.3) and Data Format Identifier (see Section 2.1.1.5).
2.2 SITP Set Service
The SITP Set Service is used by a Manager to set control data on
an Agent. Control data is data used to regulate and direct an
Agent. For example, control data can specify which events an
Agent should audit or which filters to use when an Agent pushes
data to the Manager. After the request is made, the Manager ini-
tiates a close waiting to the underlying TCP connection. The
Agent will process the request and use the same connection to
send its response. Figure 4 illustrates the SITP Set Service.
The SITP Set Service is defined by the SITP Set
Request/Indication and SITP Set Response/Confirmation service
primitives.
Manager Agent
| |
SITP-SET.request -->|------>|--> SITP-SET.indication
| |
SITP-SET.confirmation <--|<------|<-- SITP-SET.response
| |
Figure 4. SITP Set Service
Paramax Systems Corporation Expiration: December 1, 1992
[Page 10]
Internet Draft SITP June 1, 1992
2.2.1 SITP Set Request PDU
The following format defines an SITP Set Request Protocol Data
Unit (PDU):
Field #Octets Type Status
----- ------- ---- ------
Length 2 unsigned integer Mandatory
PDU Type Identifier 1 unsigned integer Mandatory
Application Identifier 1 unsigned integer Mandatory
Processing Qualifier 1 unsigned integer Mandatory
Data Format Identifier 1 unsigned integer Mandatory
Set Request Identifier 2 unsigned integer Mandatory
Field Count 2 unsigned integer Optional
Field Identifier 2 unsigned integer Optional
Field Length 2 unsigned integer Optional
Field Value Variable octet string Optional
2.2.1.1 Length
The Length field contains the total length of the SITP Set Re-
quest PDU (including the Length field) in octets. The maximum
size of a single SITP Set Request PDU is 65,535 octets.
2.2.1.2 PDU Type Identifier
A PDU Type Identifier of 3 uniquely identifies a SITP Set Request
PDU.
2.2.1.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 2.1.1.3.
2.2.1.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 2.1.1.4.
2.2.1.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 2.1.1.5.
2.2.1.6 Set Request Identifier
The Set Request Identifier uniquely identifies an SITP Set Re-
quest PDU. A single SITP Set Response is used to respond to an
SITP Set Request.
2.2.1.7 Field Count
The Field Count specifies the number of fields appearing in this
SITP Set Request PDU. The specific semantics of the field values
depend on the application. The Field Identifier, Field Length,
and Field Value fields appear Field Count times, as follows:
Paramax Systems Corporation Expiration: December 1, 1992
[Page 11]
Internet Draft SITP June 1, 1992
Field Count (N),
Field Identifier 1,
Field Length 1,
Field Value 1,
Field Identifier 2,
Field Length 2,
Field Value 2,
...
Field Identifier N,
Field Length N, and
Field Value N.
2.2.1.8 Field Identifier
The Field Identifier specifies the data fields to set. The syn-
tax and semantics of a Field Identifier value is dependent on the
Application Identifier (see Section 2.1.1.3) and Data Format
Identifier (see Section 2.1.1.5).
2.2.1.9 Field Length
The Field Length specifies the length of the field value in oc-
tets.
2.2.1.10 Field Value
The Field Value contains the value of the field.
2.2.2 SITP Set Response PDU
The following format defines an SITP Set Response PDU:
Field #Octets Type Status
----- ------- ---- ------
Length 2 unsigned integer Mandatory
PDU Type Identifier 1 unsigned integer Mandatory
Application Identifier 1 unsigned integer Mandatory
Processing Qualifier 1 unsigned integer Mandatory
Data Format Identifier 1 unsigned integer Mandatory
Set Request Identifier 2 unsigned integer Mandatory
Status 1 unsigned integer Mandatory
2.2.2.1 Length
The Length field contains the total length of the SITP Set
Response PDU (including the Length field) in octets. The size of
a single SITP Set Response PDU is nine (9) octets.
2.2.2.2 PDU Type Identifier
The PDU Type Identifier of 4 uniquely identifies an SITP Set
Response PDU.
Paramax Systems Corporation Expiration: December 1, 1992
[Page 12]
Internet Draft SITP June 1, 1992
2.2.2.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 2.1.1.3.
2.2.2.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 2.1.1.4.
2.2.2.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 2.1.1.5.
2.2.2.6 Set Request Identifier
The Set Request Identifier contains the Set Request Identifier of
the SITP Set Request PDU that prompted this SITP Set Response.
2.2.2.7 Status
The Status field reflects the possible status values of the SITP
Set Response. The five defined values for the status field are:
Value Meaning
0 Success
1 Field Identified Exists, But Unable To Set
2 Field Identified Does Not Exist
3 Unable To Process Request Temporarily
4 Unable To Process Request Permanently
A status value of zero (0) indicates that the fields specified
were set. A status value of one (1) indicates that while the
field identified does exist, the Agent was unable to set its
field values as specified by the Manager. A status value of two
(2) indicates that the field identified does not exist. A status
value of three (3) indicates that the Agent is temporarily not
able to process the request. The Manager determines when to re-
try. A status value of four (4) indicates that the Agent is per-
manently unable to process the request for some reason and the
Manager should not try the same request. When determining which
status value to return, the lowest number status value that ap-
plies should be used.
2.3 SITP Data Service
The SITP Data Service is used by an Agent to push data to a
Manager. The SITP Data PDUs are sent unsolicited by the Agent to
the Manager. After the requests are sent, the Agent initiates a
close waiting to the underlying TCP connection. The Manager, at
its option, may choose to ignore the Agents request to close the
first TCP connection and instead use the same connection to send
its response. Alternatively, the Manager may close the first TCP
connection and open a new connection to send its response. After
the Manager has safely stored the received data (or has timed out
Paramax Systems Corporation Expiration: December 1, 1992
[Page 13]
Internet Draft SITP June 1, 1992
waiting to receive all of the data), it sends an SITP Data Ack-
nowledgement PDU to the Agent and closes the TCP connection.
Figure 5 illustrates the SITP Data Service. The SITP Data Ser-
vice is defined by the SITP Data Request/Indication and SITP Data
Response/Confirmation Service Primitives.
Manager Agent
| |
SITP-DATA.indication <--|<------|<-- SITP-DATA.request
SITP-DATA.indication <--|<------|<-- SITP-DATA.request
SITP-DATA.indication <--|<------|<-- SITP-DATA.request
| |
SITP-DATA.response -->|------>|--> SITP-DATA.confirmation
| |
Figure 5. SITP Data Service
An Agent may choose to use several SITP Data PDUs to transfer the
data. Collectively, these SITP Data PDUs are known as a batch,
and are assigned a batch identifier by the Agent. Rather than
have each SITP Data PDU acknowledged by the Manager individually,
which would increase the amount of traffic on the network and the
processing time on the peer systems, the batch identifier is used
by the Manager to confirm that an entire batch of SITP Data PDUs
was safely stored on the Managers system. The Agent can deter-
mine the frequency of acknowledgements it receives from the
Manager by varying the batch size. An acknowledgement from the
Manager not only acknowledges that it has received the data, but
it also indicates that the data has been safely stored at the
Manager. By receiving this acknowledgement, the Agent can
prevent premature deletion and resulting loss of data.
2.3.1 SITP Data PDU
The following format defines an SITP Data PDU:
Field #Octets Type Status
----- ------- ---- ------
Length 2 unsigned integer Mandatory
PDU Type Identifier 1 unsigned integer Mandatory
Application Identifier 1 unsigned integer Mandatory
Processing Qualifier 1 unsigned integer Mandatory
Data Format Identifier 1 unsigned integer Mandatory
Batch Identifier 2 unsigned integer Mandatory
Status 1 unsigned integer Mandatory
Data Variable octet string Optional
2.3.1.1 Length
The Length field contains the total length of the SITP Data PDU
(including the Length field) in octets. The maximum size of a
single SITP Data PDU is 65,535 octets.
Paramax Systems Corporation Expiration: December 1, 1992
[Page 14]
Internet Draft SITP June 1, 1992
2.3.1.2 PDU Type Identifier
The PDU Type Identifier of 5 uniquely identifies an SITP Data
PDU.
2.3.1.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 2.1.1.3.
2.3.1.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 2.1.1.4.
2.3.1.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 2.1.1.5.
2.3.1.6 Batch Identifier
The Batch Identifier uniquely identifies a group of SITP Data
PDUs being pushed to the Manager.
2.3.1.7 Status
The Status field reflects the status of the SITP Data PDU. The
three values for the status field are:
Value Meaning
0 More Data Coming
1 No More Data
2 Cancel Push
If more than one SITP Data PDU is being sent in this batch, the
status field will be set to zero (0) for all SITP Data PDUs in
the batch, except the final one for which the status field will
be set to one (1). A status value of two (2) indicates the Agent
is canceling pushing this batch of data to the Manager.
2.3.1.8 Data
The Data field contains the data being pushed. The format of the
data is defined by the Application Identifier (see Section
2.1.1.3) and Data Format Identifier (see Section 2.1.1.5).
2.3.2 SITP Data Acknowledgement PDU
The following format defines an SITP Data Acknowledgement PDU:
Paramax Systems Corporation Expiration: December 1, 1992
[Page 15]
Internet Draft SITP June 1, 1992
Field #Octets Type Status
----- ------- ---- ------
Length 2 unsigned integer Mandatory
PDU Type Identifier 1 unsigned integer Mandatory
Application Identifier 1 unsigned integer Mandatory
Processing Qualifier 1 unsigned integer Mandatory
Data Format Identifier 1 unsigned integer Mandatory
Batch Identifier 2 unsigned integer Mandatory
Status 1 unsigned integer Mandatory
2.3.2.1 Length
The Length field contains the total length of the SITP Data Ack-
nowledgement PDU (including the Length field) in octets. The
size of a single SITP Data Acknowledgement PDU is nine (9) oc-
tets.
2.3.2.2 PDU Type Identifier
The PDU Type Identifier of 6 uniquely identifies an SITP Data
Acknowledgement PDU.
2.3.2.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 2.1.1.3.
2.3.2.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 2.1.1.4.
2.3.2.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 2.1.1.5.
2.3.2.6 Batch Identifier
The Batch Identifier uniquely identifies a group of SITP Data
PDUs pushed to the Manager. The value of the Batch Identifier is
provided in the SITP Data PDU.
2.3.2.7 Status
The Status field reflects the status at the Manager for a batch
of SITP Data PDUs pushed to the Manager. The five values for the
status field are:
Value Meaning
0 Data Safely Stored
1 Time Out
2 Cancel Received
3 Unable To Process Request Temporarily
4 Unable To Process Request Permanently
Paramax Systems Corporation Expiration: December 1, 1992
[Page 16]
Internet Draft SITP June 1, 1992
A status value of zero (0) signifies the data was safely stored
on the Manager. In the event the Agent does not send an entire
batch of SITP Data PDUs in a timely manner (e.g., the Agent
crashes while pushing data), the Manager may not see the status
value of No More Data in a SITP Data PDU. In such instances, the
Manager may time out after an appropriate time period, remove the
data sent to it, and return a status value of one (1). A status
value of two (2) acknowledges the Agents cancel while pushing
data. The Agent may resend the same data at a later time. A
status value of three (3) indicates the Manager is not currently
able to safely store the pushed data for some reason (e.g.,
Managers disk space is full). The Agent can try again at a later
time. A status value of four (4) indicates the Manager is not
capable of processing the pushed data at any time, and the Agent
should not try to push the same data to the Manager again. When
determining which status value to return, the lowest number
status value that applies should be used.
2.4 SITP Cancel Service
The SITP Cancel Service is used by a Manager to cancel a previ-
ously issued and unfulfilled SITP Get Request. The Get Request
Identifier in the SITP Cancel Request specifies the SITP Get Re-
quest to cancel. After the request is made, the Manager ini-
tiates a close waiting to the underlying TCP connection. The
Agent, at its option, may choose to ignore the Managers request
to close the first TCP connection and instead use the same con-
nection to send the response. Alternatively, the Agent may close
the first TCP connection and open a new connection to send its
response. The Agent will usually use the same connection that it
received the Cancel Request on to send its response. Figure 6
illustrates the SITP Cancel Service. The SITP Cancel Service is
defined by the SITP Cancel Request/Indication and SITP Cancel
Response/Confirmation Service Primitives.
Manager Agent
| |
SITP-CANCEL.request -->|------>|--> SITP-CANCEL.indication
| |
SITP-CANCEL.confirmation <--|<------|<-- SITP-CANCEL.response
| |
Figure 6. SITP Cancel Service
Paramax Systems Corporation Expiration: December 1, 1992
[Page 17]
Internet Draft SITP June 1, 1992
2.4.1 SITP Cancel Request PDU
The following format defines an SITP Cancel Request PDU:
Field #Octets Type Status
----- ------- ---- ------
Length 2 unsigned integer Mandatory
PDU Type Identifier 1 unsigned integer Mandatory
Application Identifier 1 unsigned integer Mandatory
Processing Qualifier 1 unsigned integer Mandatory
Data Format Identifier 1 unsigned integer Mandatory
Get Request Identifier 2 unsigned integer Mandatory
2.4.1.1 Length
The Length field contains the length of the SITP Cancel Request
PDU in octets. The size of a single SITP Cancel Request PDU is
eight (8) octets.
2.4.1.2 PDU Type Identifier
The PDU Type Identifier of 7 uniquely identifies an SITP Cancel
Request PDU.
2.4.1.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 2.1.1.3.
2.4.1.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 2.1.1.4.
2.4.1.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 2.1.1.5.
2.4.1.6 Get Request Identifier
The Get Request Identifier specifies the SITP Get Request to can-
cel from being processed. A Get Request Identifier value of zero
(0) cancels all previously issued and unfulfilled SITP Get Re-
quests at the Agent.
Paramax Systems Corporation Expiration: December 1, 1992
[Page 18]
Internet Draft SITP June 1, 1992
2.4.2 SITP Cancel Response PDU
The following format defines an SITP Cancel Response PDU:
Field #Octets Type Status
----- ------- ---- ------
Length 2 unsigned integer Mandatory
PDU Type Identifier 1 unsigned integer Mandatory
Application Identifier 1 unsigned integer Mandatory
Processing Qualifier 1 unsigned integer Mandatory
Data Format Identifier 1 unsigned integer Mandatory
Get Request Identifier 2 unsigned integer Mandatory
Status 1 unsigned integer Mandatory
2.4.2.1 Length
The Length field contains the length of the SITP Cancel Response
PDU in octets. The size of a single SITP Cancel Response PDU is
nine (9) octets.
2.4.2.2 PDU Type Identifier
The PDU Type Identifier of 8 uniquely identifies an SITP Cancel
Response PDU.
2.4.2.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 2.1.1.3.
2.4.2.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 2.1.1.4.
2.4.2.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 2.1.1.5.
2.4.2.6 Get Request Identifier
The Get Request Identifier specifies the SITP Get Request can-
celed. A Get Request Identifier value of zero (0) indicates that
all previously issued and unfulfilled SITP Get Requests have been
canceled at the Agent.
2.4.2.7 Status
The Status field reflects the status for a SITP Cancel Request.
The two values for the status field are:
0 Get Request Canceled
1 Unable To Cancel Get Request
Paramax Systems Corporation Expiration: December 1, 1992
[Page 19]
Internet Draft SITP June 1, 1992
3. SITP AND AUDITING
3.1 Common Audit Formats
The initial motivation to write this document was to define a
standard protocol for centralized audit collection. Several or-
ganizations have expressed a need for SITP, including the MITRE
Corporation [Ramsey91, Schaen91], Rome Laboratory [Shobert91],
and the Strategic Air Command (SAC). An earlier version of SITP
has been implemented and operational for over a year at an Air
Force Department of Defense Intelligence Information System (DO-
DIIS) site for centralized audit collection using a DNSIX speci-
fied network audit data format [DIA90a-b].
Centralized audit analysis in a distributed, heterogeneous en-
vironment is complicated by the fact that each end and intermedi-
ate system may audit different events and store different data
for each event. SITP is a standard protocol for transferring au-
dit data, but it does not include the specific events a system
should audit, nor does it include the data that should be stored
for each event. It is up to the audit applications to understand
and interpret the data requested and received. For centralized
processing and analysis of audit data, a common audit format must
be defined. Companion RFCs may be issued to define audit and
other formats for major communities of interest, such as the DOD
intelligence community.
3.2 Audit Collection Versus Audit Control
Audit collection retrieves audit data and/or audit filter values
used when a push occurs on a remote system. Audit control sets
values on a system that control how the system operates. For ex-
ample, setting the filter values used when a push occurs.
3.3 Protection of Audit Data
To insure the integrity of transferred audit data, communications
between systems must be authenticated and protected. SITP does
not provide this protection. If such protection is required in a
particular environment, it will need to be provided externally to
SITP.
3.4 SITP versus CMOT and SNMP for Audit Collection
Some have proposed using ISO/OSI's Common Management Information
Protocol (CMIP) Over TCP (CMOT) for centralized audit collection.
Both CMOT and SITP support filters and require the services of a
reliable, connection-oriented transport protocol like TCP. While
it may be technically possible to use CMOT to collect audit data,
it is a much larger protocol than SITP because it was designed as
a general purpose management protocol. SITP was originally
designed specifically for audit management. Additionally, CMOT
seems to be fading from view and is no longer under consideration
for managing TCP/IP. The Simple Network Management Protocol
(SNMP) is the dominate protocol for this purpose.
Paramax Systems Corporation Expiration: December 1, 1992
[Page 20]
Internet Draft SITP June 1, 1992
There are two main reasons for not using SNMP for audit collec-
tion. First SNMP runs over UDP, an unreliable transport proto-
col. Most audit applications will probably require a reliable
transport protocol. Second, SNMP was designed to support small
data transfers and is not appropriate or efficient for bulk
transfers.
Paramax Systems Corporation Expiration: December 1, 1992
[Page 21]
Internet Draft SITP June 1, 1992
4. REFERENCES
[DIA90a] LaPadula, L.J., J.E. LeMoine, D.F. Vukelich, J.L.
Berger, J.P.L. Woodward, DNSIX Interface Specifica-
tions, Version 2, DIA Document Number DDS-2600-5984-90,
April 1990.
[DIA90b] LaPadula, L.J., J.E. LeMoine, D.F. Vukelich, J.L.
Berger, J.P.L. Woodward, DNSIX Detailed Design Specif-
ication, Version 2, DIA Document Number DDS-2600-5985-
90, April 1990.
[Ramsey91] Ramsey, Wally, Centralized Management of Audit Data in
the SAC IDHS, DRAFT, MITRE Corporation, 1991.
[RFC-1157] Case, J., M. Fedor, M. Schoffstall, and J. Davin, A
Simple Network Management Protocol (SNMP), RFC 1157,
May 1990.
[Schaen91] Schaen, S.I., and B.W. McKenney, Research, Standards
and Policy Directions for Network Auditing, presented
at Intrusion Detection Workshop, Menlo Park, Ca., May
1991.
[Shobert91] Captain Bill Shobert, Auditing Section in Technical De-
tails for Workstation Interfaces, DRAFT, AFIA, 1991.
5. ACKNOWLEDGEMENTS
The authors would like to thank the following individuals for
providing valuable comments with regard to this document: Wally
Ramsey from MITRE Corporation and Ryan Stoutenborough, Larry
Lavenberg, Dave Barch, Tony Mallich, and Clark Weissman from
Paramax Systems Corporation.
6. AUTHORS' ADDRESS
John Dempsey
Carl Feil
Nina Lewis
Paramax Systems Corporation
5151 Camino Ruiz
Camarillo, California 93011
Phone: (805) 987-6811
EMail: john@cam.unisys.com
feil@cam.unisys.com
nina@cam.unisys.com
Paramax Systems Corporation Expiration: December 1, 1992
[Page 22]