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]