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]