Internet DRAFT - draft-dempsey-audit-info
draft-dempsey-audit-info
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:34:56 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 09 Dec 1992 04:33:00 GMT
ETag: "3ddd81-d8fd-2b2576fc"
Accept-Ranges: bytes
Content-Length: 55549
Connection: close
Content-Type: text/plain
Network Working Group J. Dempsey
INTERNET-DRAFT C. Feil
N. Lewis
Paramax Systems Corporation
August 11, 1992
AUDIT INFORMATION TRANSFER PROTOCOL (AITP)
Status of this Memo
This memo defines the Audit Information Transfer Protocol (AITP)
used to send and receive audit information between systems. AITP
requires a reliable connection-oriented transport protocol, such
as TCP. An initiator can use AITP to request audit data from a
responder, to set data filters, and to set remote audit manage-
ment parameters. The responder handles the request and sets
parameters or returns the requested data. AITP has been proposed
by the Trusted System Interoperability Group as the protocol of
choice for audit information transfer. This document supersedes
the July 1991 Internet Draft entitled Security Information
Transfer Protocol (SITP). Distribution of this memo is unlimit-
ed.
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 Inter-
net 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: February 11, 1993
[Page 1]
Internet Draft AITP August 11, 1992
Table of Contents
1. INTRODUCTION 3
1.1 AITP Versus CMOT And SNMP For Audit Collection 3
1.2 Network Architectures 3
1.3 Storage of Data 5
1.4 Transfer of Data 5
2. AITP AND AUDITING 6
2.1 Common Audit Formats 6
2.2 Audit Collection Versus Audit Control 6
2.3 Protection of Audit Data 6
3. AITP SERVICES 7
3.1 AITP Get Service 11
3.2 AITP Set Service 16
3.3 AITP Data Service 19
3.4 AITP Cancel Service 22
4. REFERENCES 22
5. ACKNOWLEDGEMENTS 22
6. AUTHORS' ADDRESS 22
Paramax Systems Corporation Expiration: February 11, 1993
[Page 2]
Internet Draft AITP August 11, 1992
1. INTRODUCTION
This document defines the Audit Information Transfer Protocol
(AITP), a simple transaction protocol suitable for transferring
audit information between systems. An initiator can use AITP to
request audit data from, or set audit 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 audit data returned can be very
large. These are the main reasons for a unique protocol to sup-
port this type of service.
Although AITP could be used to transfer other security informa-
tion, such as discretionary access control data and general secu-
rity administration data, our initial motivation to write this
document was to define a standard protocol for centralized audit
collection. Several organizations have expressed a need for
AITP, including the MITRE Corporation [Ramsey91, Schaen91], Rome
Laboratory [Shobert91], and the Strategic Air Command (SAC). An
earlier version of AITP has been implemented and operational for
over a year at an Air Force Department of Defense Intelligence
Information System (DODIIS) site for centralized audit collection
using a DNSIX specified network audit data format [DIA90a-b].
1.1 AITP versus CMOT and SNMP for Audit Collection
Some have proposed using ISO/OSIs Common Management Information
Protocol (CMIP) Over TCP (CMOT) [RFC-1095] for centralized audit
collection. Both CMOT and AITP 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, CMOT is substantially larger than AITP be-
cause it was designed as a general purpose management protocol.
AITP, on the other hand, was designed specifically for audit
management. Additionally, CMOT seems to be no longer under con-
sideration for managing TCP/IP networks. The Simple Network
Management Protocol (SNMP) [RFC-1157] has emerged as the dominant
protocol for this purpose.
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 such as are required here.
1.2 Network Architectures
Using a minimal number of services, AITP can support various net-
work architectures, such as manager/agent, client/server, and
peer-to-peer. The format of the data transferred by AITP is
application-specific. Therefore, for an application using AITP,
a separate document or RFC is needed to define the syntax and se-
mantics of the transferred data.
Paramax Systems Corporation Expiration: February 11, 1993
[Page 3]
Internet Draft AITP August 11, 1992
Figure 1 illustrates the hierarchical structure that typically
exists between Managers and Agents. Using AITP, 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).
Audit applications may use the manager/agent architecture, where
the data being transferred may be audit or security alert data.
For these 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 sufficient local storage, the audit
data may be sent unsolicited to the Manager using AITP. 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.
Figure 1 also illustrates an xManager serving two xAgents. The
dashed lines between the xManager and xAgents indicate that a
protocol other than AITP is being used for this interaction. The
Agent, which co-resides with the xManager, uses AITP 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.
Paramax Systems Corporation Expiration: February 11, 1993
[Page 4]
Internet Draft AITP August 11, 1992
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 AITP functionality in
terms of the Manager/Agent architecture, but keep in mind it is
suitable for other architectures as well.
1.3 Storage of Data
AITP supports an abstract, virtual view of how data is stored on
an end system. This view includes independent data items,
tables, and fields within tables. This view is not intended to
force any specific implementation for actual data storage.
1.4 Transfer of Data
AITP supports two basic modes of operation: push and pull. Unsol-
icited data sent from an Agent to a Manager is said to be pushed.
For example, security alert data that indicates a special event
on an Agents system should be pushed to the Manager. Additional-
ly, collected data that cannot be stored locally (e.g., audit
data on a network device) may be pushed to the Manager. In gen-
eral, data is pushed to a Manager for analysis and long term
storage to a backup medium such as tape.
One or two transport connections may be used to push data. The
first connection, initiated by the Agent, is used to send the
data. The second 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 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 transport connections are used to
pull data. The first connection, initiated by the Manager, is
used to send the data request. The second connection, initiated
by the Agent, is used to send the requested data. At its discre-
tion, an Agent may optionally use the same 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 connection should be used for the
response. All responses to a request must be returned on a sin-
gle 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
Paramax Systems Corporation Expiration: February 11, 1993
[Page 5]
Internet Draft AITP August 11, 1992
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.
AITP uses standard transport 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. AITP AND AUDITING
2.1 Common Audit Formats
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. AITP 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.
2.2 Audit Collection versus Audit Control
We envision at least two reasonable audit applications: audit
collection and audit control. The audit collection application
would retrieve audit data and the audit filter values used by a
remote system to filter the audit data pushed to another loca-
tion. The audit control application would set parameters on re-
mote systems to control how those systems collect audit data lo-
cally.
2.3 Protection of Audit Data
To insure the integrity of transferred audit data, communications
between systems must be authenticated and protected. AITP does
not provide this protection. If such protection is required in a
particular environment, it will need to be provided externally to
AITP.
Paramax Systems Corporation Expiration: February 11, 1993
[Page 6]
Internet Draft AITP August 11, 1992
3. AITP SERVICES
There are four AITP services:
1. AITP Get
2. AITP Set
3. AITP Data
4. AITP Cancel
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
------------------ ------- ----- ------ ------ ----
AITP-GET.request M O O M M
AITP-GET.response O M M O M
AITP-SET.request O O O O O
AITP-SET.response O M O O M
AITP-DATA.request O M M O M
AITP-DATA.response M O O M M
AITP-CANCEL.request M O O M M
AITP-CANCEL.response O M M O M
Table 1. AITP Services
3.1 AITP Get Service
The AITP Get Service is used by a Manager to request data from an
Agent. After the request is made, the Agent usually sends an in-
terim response, closes the first transport connection, and then
processes the request. When the Agent is ready to send the data,
a second transport connection is opened by the Agent. The Agent,
at its option, may use the same transport connection to transfer
the data. Once the Agent is ready to send the data and the con-
nection is established, the data is sent from the Agent to the
Manager and the connection closed. Figure 3 illustrates the AITP
Get Service. The AITP Get Service is defined by the AITP Get
Request/Indication and AITP Get Response/Confirmation service
primitives. One or more Get Response Protocol Data Units (PDUs)
may be required to respond to a single Get Request. If two con-
nections are used, the first AITP Get Response PDU, which is sent
on the original connection, informs the Manager that the data
will return on a separate connection. All subsequent Get
Response PDUs must use the same connection.
Paramax Systems Corporation Expiration: February 11, 1993
[Page 7]
Internet Draft AITP August 11, 1992
Manager Agent
| |
AITP-GET.request -->|------>|--> AITP-GET.indication
| |
AITP-GET.confirmation <--|<------|<-- AITP-GET.response
AITP-GET.confirmation <--|<------|<-- AITP-GET.response
AITP-GET.confirmation <--|<------|<-- AITP-GET.response
| |
Figure 3. AITP Get Service
3.1.1 AITP Get Request PDU
The following format defines an AITP Get 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
Field Count 2 unsigned integer Optional
Field Identifier 2 unsigned integer Optional
Field Length 2 unsigned integer Optional
Field Value Variable octet string Optional
3.1.1.1 Length
The Length field contains the total length of the AITP Get Re-
quest PDU (including the Length field) in octets. The maximum
size of a single AITP Get Request PDU is 65,535 octets.
3.1.1.2 PDU Type Identifier
A PDU Type Identifier of 1 uniquely identifies a AITP Get Request
PDU.
3.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. In the TCP/IP environment, each
Application Identifier is associated with one well known TCP port
number for receiving new incoming connections. Outgoing data can
use any unassigned port number locally.
3.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
Paramax Systems Corporation Expiration: February 11, 1993
[Page 8]
Internet Draft AITP August 11, 1992
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).
3.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.
3.1.1.6 Get Request Identifier
The Get Request Identifier uniquely identifies an AITP Get Re-
quest PDU. One or more AITP Get Responses can be used to respond
to a AITP Get Request. A Get Request Identifier of zero (0) is
reserved by the AITP Cancel Service, and should not be used in an
AITP Get Request PDU.
3.1.1.7 Field Count
The Field Count specifies the number of fields appearing in this
AITP 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 AITP Get Request PDU or should be set equal to
zero. 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.
3.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 3.1.1.3) and Data Format Iden-
tifier (see Section 3.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-
Paramax Systems Corporation Expiration: February 11, 1993
[Page 9]
Internet Draft AITP August 11, 1992
cate that its Field Value contains a list of Agents from which
data is desired.
3.1.1.9 Field Length
The Field Length specifies the length of the field value in oc-
tets.
3.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
set to userid and the field value set to john nina carl ryan.
3.1.2 AITP Get Response PDU
The following format defines an AITP 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
3.1.2.1 Length
The Length field contains the total length of the AITP Get
Response PDU (including the Length field) in octets. The maximum
size of a single AITP Get Response PDU is 65,535 octets.
3.1.2.2 PDU Type Identifier
The PDU Type Identifier of 2 uniquely identifies an AITP Get
Response PDU.
3.1.2.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 3.1.1.3.
3.1.2.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 3.1.1.4.
3.1.2.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 3.1.1.5.
Paramax Systems Corporation Expiration: February 11, 1993
[Page 10]
Internet Draft AITP August 11, 1992
3.1.2.6 Get Request Identifier
The Get Request Identifier contains the Get Request Identifier of
the AITP Get Request PDU that prompted this AITP Get Response.
3.1.2.7 Status
The Status field reflects the possible status values of the AITP
Get Response. The seven defined values for the status field are:
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
6 Data Will Return on a Separate Connection
If more than one AITP Get Response is sent in response to a re-
quest, the status field will be set to zero (0) for all AITP 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. A status value of six (6) indicates that the Agent will
return the requested data on a separate connection. This status
value also acknowledges the AITP Get Request. When determining
which status value to return, the lowest number status value that
applies should be used.
3.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
3.1.1.3) and Data Format Identifier (see Section 3.1.1.5).
3.2 AITP Set Service
The AITP 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 continu-
ally pushes unsolicited data to the Manager. After the request is
made, the Agent usually will use the same connection to send its
response. The Agent, at its option, may send the first AITP Set
Response with a status value indicating that a second connection
will be used, close the first connection, process the request,
and open a second connection to send the full response. Figure 4
illustrates the AITP Set Service. The AITP Set Service is de-
Paramax Systems Corporation Expiration: February 11, 1993
[Page 11]
Internet Draft AITP August 11, 1992
fined by the AITP Set Request/Indication and AITP Set
Response/Confirmation service primitives.
Manager Agent
| |
AITP-SET.request -->|------>|--> AITP-SET.indication
| |
AITP-SET.confirmation <--|<------|<-- AITP-SET.response
AITP-SET.confirmation <--|<------|<-- AITP-SET.response
AITP-SET.confirmation <--|<------|<-- AITP-SET.response
| |
Figure 4. AITP Set Service
3.2.1 AITP Set Request PDU
The following format defines an AITP 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
3.2.1.1 Length
The Length field contains the total length of the AITP Set Re-
quest PDU (including the Length field) in octets. The maximum
size of a single AITP Set Request PDU is 65,535 octets.
3.2.1.2 PDU Type Identifier
A PDU Type Identifier of 3 uniquely identifies a AITP Set Request
PDU.
3.2.1.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 3.1.1.3.
3.2.1.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 3.1.1.4.
3.2.1.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
Paramax Systems Corporation Expiration: February 11, 1993
[Page 12]
Internet Draft AITP August 11, 1992
data. See Section 3.1.1.5.
3.2.1.6 Set Request Identifier
The Set Request Identifier uniquely identifies an AITP Set Re-
quest PDU. A single AITP Set Response is used to respond to an
AITP Set Request.
3.2.1.7 Field Count
The Field Count specifies the number of fields appearing in this
AITP 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:
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.
3.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 3.1.1.3) and Data Format
Identifier (see Section 3.1.1.5).
3.2.1.9 Field Length
The Field Length specifies the length of the field value in oc-
tets.
3.2.1.10 Field Value
The Field Value contains the value of the field.
Paramax Systems Corporation Expiration: February 11, 1993
[Page 13]
Internet Draft AITP August 11, 1992
3.2.2 AITP Set Response PDU
The following format defines an AITP 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
Field Count 2 unsigned integer Optional
Field Identifier 2 unsigned integer Optional
Field Status 1 unsigned integer Optional
3.2.2.1 Length
The Length field contains the total length of the AITP Set
Response PDU (including the Length field) in octets. The maximum
size of a single AITP Set Response PDU is 65,535 octets.
3.2.2.2 PDU Type Identifier
The PDU Type Identifier of 4 uniquely identifies an AITP Set
Response PDU.
3.2.2.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 3.1.1.3.
3.2.2.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 3.1.1.4.
3.2.2.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 3.1.1.5.
3.2.2.6 Set Request Identifier
The Set Request Identifier contains the Set Request Identifier of
the AITP Set Request PDU that prompted this AITP Set Response.
3.2.2.7 Status
The Status field reflects the possible status values of the AITP
Set Response. The five defined values for the status field are:
Paramax Systems Corporation Expiration: February 11, 1993
[Page 14]
Internet Draft AITP August 11, 1992
Value Meaning
0 Success
1 Field Failure
2 Unable to Process Request Temporarily
3 Unable to Process Request Permanently
4 Response Will Return on a Separate Connection
A status value of zero (0) indicates that the fields specified
were set. A status value of one (1) indicates a field failure,
such as the field identified does not exist, or the field exists
but cannot be set. A status value of two (2) indicates that the
Agent is temporarily not able to process the request. The
Manager determines when to retry. A status value of three (3)
indicates that the Agent is permanently unable to process the re-
quest for some reason and the Manager should not retry the same
request. A status value of four (4) indicates that the response
will return on a separate connection. When determining which
status value to return, the lowest number status value that ap-
plies should be used.
3.2.2.8 Field Count
The Field Count specifies the number of fields that could not be
set, and that therefore appear in this AITP Set Response PDU.
The identifier and status is returned only for each field that
could not be set. The Field Identifier and Field Status appear
Field Count times, as follows:
Field Count (N),
Field Identifier 1,
Field Status 1,
Field Identifier 2,
Field Status 2,
...
Field Identifier N, and
Field Status N.
3.2.2.9 Field Identifier
The Field Identifier specifies the data field for which the set
failed. The syntax and semantics of a Field Identifier value is
dependent on the Application Identifier (see Section 3.1.1.3) and
Data Format Identifier (see Section 3.1.1.5).
3.2.2.10 Field Status
The Field Status specifies why the set failed. Valid status
values are:
Value Meaning
0 Field Identified Exists, But Unable To Set
1 Field Identified Does Not Exist
Paramax Systems Corporation Expiration: February 11, 1993
[Page 15]
Internet Draft AITP August 11, 1992
3.3 AITP Data Service
The AITP Data Service is used by an Agent to push data to a
Manager. The AITP Data PDUs are sent unsolicited by the Agent to
the Manager. After the requests are sent, the Manager may choose
to use the same transport connection to send its response. Al-
ternatively, the Manager may close the first connection and open
a new connection to send its response. After the Manager has
safely stored the received data (or has timed out waiting to re-
ceive all of the data), it sends an AITP Data Acknowledgement PDU
to the Agent and closes the connection. Figure 4 illustrates the
AITP Data Service. The AITP Data Service is defined by the AITP
Data Request/Indication and AITP Data Response/Confirmation Ser-
vice Primitives.
Manager Agent
| |
AITP-DATA.indication <--|<------|<-- AITP-DATA.request
AITP-DATA.indication <--|<------|<-- AITP-DATA.request
AITP-DATA.indication <--|<------|<-- AITP-DATA.request
| |
AITP-DATA.response -->|------>|--> AITP-DATA.confirmation
| |
Figure 5. AITP Data Service
An Agent may choose to use several AITP Data PDUs to transfer the
data. Collectively, these AITP Data PDUs are known as a batch,
and are assigned a batch identifier by the Agent. Rather than
have each AITP 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 AITP 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.
3.3.1 AITP Data PDU
The following format defines an AITP 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
Paramax Systems Corporation Expiration: February 11, 1993
[Page 16]
Internet Draft AITP August 11, 1992
3.3.1.1 Length
The Length field contains the total length of the AITP Data PDU
(including the Length field) in octets. The maximum size of a
single AITP Data PDU is 65,535 octets.
3.3.1.2 PDU Type Identifier
The PDU Type Identifier of 5 uniquely identifies an AITP Data
PDU.
3.3.1.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 3.1.1.3.
3.3.1.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 3.1.1.4.
3.3.1.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 3.1.1.5.
3.3.1.6 Batch Identifier
The Batch Identifier uniquely identifies a group of AITP Data
PDUs being pushed to the Manager.
3.3.1.7 Status
The Status field reflects the status of the AITP 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 AITP Data PDU is being sent in this batch, the
status field will be set to zero (0) for all AITP 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.
3.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
3.1.1.3) and Data Format Identifier (see Section 3.1.1.5).
Paramax Systems Corporation Expiration: February 11, 1993
[Page 17]
Internet Draft AITP August 11, 1992
3.3.2 AITP Data Acknowledgement PDU
The following format defines an AITP Data Acknowledgement 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
3.3.2.1 Length
The Length field contains the total length of the AITP Data Ack-
nowledgement PDU (including the Length field) in octets. The
size of a single AITP Data Acknowledgement PDU is nine (9) oc-
tets.
3.3.2.2 PDU Type Identifier
The PDU Type Identifier of 6 uniquely identifies an AITP Data
Acknowledgement PDU.
3.3.2.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 3.1.1.3.
3.3.2.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 3.1.1.4.
3.3.2.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 3.1.1.5.
3.3.2.6 Batch Identifier
The Batch Identifier uniquely identifies a group of AITP Data
PDUs pushed to the Manager. The value of the Batch Identifier is
provided in the AITP Data PDU.
3.3.2.7 Status
The Status field reflects the status at the Manager for a batch
of AITP Data PDUs pushed to the Manager. The five values for the
status field are:
Paramax Systems Corporation Expiration: February 11, 1993
[Page 18]
Internet Draft AITP August 11, 1992
Value Meaning
0 Data Safely Stored
1 Time Out
2 Cancel Received
3 Unable To Process Request Temporarily
4 Unable To Process Request Permanently
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 AITP 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 Datain a AITP 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.
3.4 AITP Cancel Service
The AITP Cancel Service is used by a Manager to cancel a previ-
ously issued and unfulfilled AITP Get Request. The Get Request
Identifier in the AITP Cancel Request specifies the AITP Get Re-
quest to cancel. After the request is made, the Agent must use
the same connection to send its response. Figure 5 illustrates
the AITP Cancel Service. The AITP Cancel Service is defined by
the AITP Cancel Request/Indication and AITP Cancel
Response/Confirmation Service Primitives.
Manager Agent
| |
AITP-CANCEL.request -->|------>|--> SITP-CANCEL.indication
| |
AITP-CANCEL.confirmation <--|<------|<-- SITP-CANCEL.response
| |
Figure 6. AITP Cancel Service
Paramax Systems Corporation Expiration: February 11, 1993
[Page 19]
Internet Draft AITP August 11, 1992
3.4.1 AITP Cancel Request PDU
The following format defines an AITP 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
3.4.1.1 Length
The Length field contains the length of the AITP Cancel Request
PDU in octets. The size of a single AITP Cancel Request PDU is
eight (8) octets.
3.4.1.2 PDU Type Identifier
The PDU Type Identifier of 7 uniquely identifies an AITP Cancel
Request PDU.
3.4.1.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 3.1.1.3.
3.4.1.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 3.1.1.4.
3.4.1.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 3.1.1.5.
3.4.1.6 Get Request Identifier
The Get Request Identifier specifies the AITP Get Request to can-
cel from being processed. A Get Request Identifier value of zero
(0) cancels all previously issued and unfulfilled AITP Get Re-
quests at the Agent.
Paramax Systems Corporation Expiration: February 11, 1993
[Page 20]
Internet Draft AITP August 11, 1992
3.4.2 AITP Cancel Response PDU
The following format defines an AITP 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
3.4.2.1 Length
The Length field contains the length of the AITP Cancel Response
PDU in octets. The size of a single AITP Cancel Response PDU is
nine (9) octets.
3.4.2.2 PDU Type Identifier
The PDU Type Identifier of 8 uniquely identifies an AITP Cancel
Response PDU.
2.4.2.3 Application Identifier
The Application Identifier uniquely identifies the application.
See Section 3.1.1.3.
3.4.2.4 Processing Qualifier
The Processing Qualifier stipulates how to process the data. See
Section 3.1.1.4.
3.4.2.5 Data Format Identifier
The Data Format Identifier uniquely identifies the format of
data. See Section 3.1.1.5.
3.4.2.6 Get Request Identifier
The Get Request Identifier specifies the AITP Get Request can-
celed. A Get Request Identifier value of zero (0) indicates that
all previously issued and unfulfilled AITP Get Requests have been
canceled at the Agent.
3.4.2.7 Status
The Status field reflects the status for a AITP Cancel Request.
The two values for the status field are:
0 Get Request Canceled
1 Unable To Cancel Get Request
Paramax Systems Corporation Expiration: February 11, 1993
[Page 21]
Internet Draft AITP August 11, 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-1095] Warrier, U.S. and L. Besaw, Common Management Informa-
tion Services and Protocol Over TCP/IP (CMOT), RFC
1095, April 1989.
[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: February 11, 1993
[Page 22]
