OpenC2 Actuator Profile for Packet Filtering Version 1.0

Committee Specification Draft 01

21 July 2021

 

This stage:

https://docs.oasis-open.org/openc2/ap-pf/v1.0/csd01/ap-pf-v1.0-csd01.md (Authoritative)
https://docs.oasis-open.org/openc2/ap-pf/v1.0/csd01/ap-pf-v1.0-csd01.html
https://docs.oasis-open.org/openc2/ap-pf/v1.0/csd01/ap-pf-v1.0-csd01.pdf

Previous stage:

N/A

Latest stage:

https://docs.oasis-open.org/openc2/ap-pf/v1.0/ap-pf-v1.0.md (Authoritative)
https://docs.oasis-open.org/openc2/ap-pf/v1.0/ap-pf-v1.0.html
https://docs.oasis-open.org/openc2/ap-pf/v1.0/ap-pf-v1.0.pdf

Technical Committee:

OASIS Open Command and Control (OpenC2) TC

Chair:

Duncan Sparrell (duncan@sfractal.com), sFractal Consulting LLC

Editors:

Alex Everett (alex.everett@unc.edu), University of North Carolina, Chapel Hill
Vasileios Mavroeidis (vasileim@ifi.uio.no), University of Oslo

Abstract:

Open Command and Control (OpenC2) is a concise and extensible language to enable the command and control of cyber defense components, subsystems and/or systems in a manner that is agnostic of the underlying products, technologies, transport mechanisms or other aspects of the implementation. Packet filtering is a cyber defense mechanism that denies or allows traffic based on static or dynamic properties of the traffic, such as address, port, protocol, etc. This profile defines the Actions, Targets, Specifiers and Options that are consistent with the Version 1.0 of the OpenC2 Language Specification ([OpenC2-Lang-v1.0]) in the context of packet filtering (PF).

Status:

This document was last revised or approved by the OASIS Open Command and Control (OpenC2) TC on the above date. The level of approval is also listed above. Check the "Latest stage" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2#technical.

TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/openc2/.

This specification is provided under the Non-Assertion Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (https://www.oasis-open.org/committees/openc2/ipr.php).

Note that any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.

Key words:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.

Citation format:

When referencing this specification the following citation format should be used:

[OpenC2-PF-v1.0] OpenC2 Actuator Profile for Packet Filtering Version 1.0. Edited by Alex Everett and Vasileios Mavroeidis. 21 July 2021. OASIS Committee Specification Draft 01. https://docs.oasis-open.org/openc2/ap-pf/v1.0/csd01/ap-pf-v1.0-csd01.html. Latest stage: https://docs.oasis-open.org/openc2/ap-pf/v1.0/ap-pf-v1.0.html.

Notices:

Copyright © OASIS Open 2021. All Rights Reserved.

Distributed under the terms of the OASIS IPR Policy.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs.

For complete copyright information please see the Notices section in the Appendix.

Table of Contents

1 Introduction

The content in this section is non-normative, except where it is marked normative.

OpenC2 is a suite of specifications that enables command and control of cyber defense systems and components. OpenC2 typically uses a request-response paradigm where a Command is encoded by a Producer (managing application) and transferred to a Consumer (managed device or virtualized function) using a secure transfer protocol, and the Consumer can respond with status and any requested information.

OpenC2 allows the application producing the commands to discover the set of capabilities supported by the managed devices. These capabilities permit the managing application to adjust its behavior to take advantage of the features exposed by the managed device. The capability definitions can be easily extended in a noncentralized manner, allowing standard and non-standard capabilities to be defined with semantic and syntactic rigor.

1.1 IPR Policy

This specification is provided under the Non-Assertion Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (https://www.oasis-open.org/committees/openc2/ipr.php).

1.2 Terminology

This section is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.3 Document Conventions

1.3.1 Naming Conventions

1.3.2 Font Colors and Style

The following color, font and font style conventions are used in this document:

Example:

{
    "action": "deny",
    "target": {
        "file": {
            "hashes": {
                "sha256": "22fe72a34f006ea67d26bb7004e2b6941b5c3953d43ae7ec24d41b1a928a6973"
            }
        }
    }
}

1.4 Overview

In general, there are two types of participants involved in the exchange of OpenC2 Messages, as depicted in Figure 1-1:

  1. Producers: A Producer is an entity that creates Commands to provide instruction to one or more systems to act in accordance with the content of the Command. A Producer may receive and process Responses in conjunction with a Command.
  2. Consumers: A Consumer is an entity that receives and may act upon a Command. A Consumer may create Responses that provide any information captured or necessary to send back to the Producer.

OpenC2 Message Exchange

Figure 1-1. OpenC2 Message Exchange

OpenC2 is a suite of specifications for Producers and Consumers to command and execute cyber defense functions. These specifications include the OpenC2 Language Specification, Actuator Profiles, and Transfer Specifications. The OpenC2 Language Specification and Actuator Profile specifications focus on the language content and meaning at the Producer and Consumer of the Command and Response while the transfer specifications focus on the protocols for their exchange.

The OpenC2 Language Specification defines a language used to compose Messages for command and control of cyber defense systems and components. A Message consists of a header and a payload (defined as a Message body in the OpenC2 Language Specification Version 1.0 and specified in one or more Actuator profiles).

The language defines two payload structures:

  1. Command: An instruction from one system known as the Producer, to one or more systems, the Consumer(s), to act on the content of the Command.
  2. Response: Any information sent back to the Producer as a result of the Command.

OpenC2 implementations integrate the related OpenC2 specifications described above with related industry specifications, protocols, and standards. Figure 1-2 depicts the relationships among OpenC2 specifications, and their relationships to other industry standards and environment-specific implementations of OpenC2. Note that the layering of implementation aspects in the diagram is notional, and not intended to preclude any particular approach to implementing the needed functionality (for example, the use of an application-layer message signature function to provide message source authentication and integrity).

OpenC2 Documentation and Layering Model

Figure 1-2. OpenC2 Documentation and Layering Model

OpenC2 is conceptually partitioned into four layers as shown in Table 1-1.

Table 1-1. OpenC2 Protocol Layers

Layer Examples
Function-Specific Content Actuator Profiles
(standard and extensions)
Common Content Language Specification
[OpenC2-Lang-v1.0]
Message Transfer Specifications
([OpenC2-HTTPS-v1.0], OpenC2-over-CoAP, ...)
Secure Transport HTTPS, CoAP, MQTT, OpenDXL, ...

The components of a Command are an Action (what is to be done), a Target (what is being acted upon), an optional Actuator (what is performing the command), and Command Arguments, which influence how the Command is to be performed. An Action coupled with a Target is sufficient to describe a complete Command. Though optional, the inclusion of an Actuator and/or Command Arguments provides additional precision to a Command.

The components of a Response are a numerical status code, an optional status text string, and optional results. The format of the results, if included, depend on the type of Response being transferred.

1.5 Goal

The goal of the OpenC2 Language Specification is to provide a language for interoperating between functional elements of cyber defense systems. This language used in conjunction with OpenC2 Actuator Profiles and OpenC2 Transfer Specifications allows for vendor-agnostic cybertime response to attacks.

The Integrated Adaptive Cyber Defense (IACD) framework defines a collection of activities, based on the traditional OODA (Observe–Orient–Decide–Act) Loop [IACD]:

The goal of OpenC2 is to enable coordinated defense in cyber-relevant time between decoupled blocks that perform cyber defense functions. OpenC2 focuses on the Acting portion of the IACD framework; the assumption that underlies the design of OpenC2 is that the sensing/analytics have been provisioned and the decision to act has been made. This goal and these assumptions guide the design of OpenC2:

1.6 Purpose and Scope

A packet filter (PF) is a policy enforcement mechanism that restricts or permits traffic based on static or dynamic values such as source address, destination address, payload, and/or port numbers. A Packet Filter may consider traffic patterns, connection state, data flows, applications, or payload information. The scope of this profile is limited to network Packet Filtering herein referred to as PF.

This Actuator profile specifies the set of Actions, Targets, Specifiers, and Command Arguments that integrates PF functionality with the Open Command and Control (OpenC2) Command set. Through this Command set, cyber security orchestrators may gain visibility into and provide control over the PF functionality in a manner that is independent of the instance of the PF function.

All components, devices and systems that provide PF functionality will implement the OpenC2 Actions, Targets, Specifiers and Arguments identified as required in this document. Actions that are applicable, but not necessarily required, for PF will be identified as optional.

The purpose of this document is to:

This PF profile:

Cyber defense systems that are utilizing OpenC2 may require the following components to implement the PF profile:

Though cyber defense components, devices, systems and/or instances may implement multiple Actuator profiles, a particular OpenC2 Message may reference at most a single Actuator profile. The scope of this document is limited to PF.

This specification is organized into three major sections.

Section One (this section) provides a non-normative overview of the suite of specifications that realize OpenC2. This section provides references as well as defines the scope and purpose of this specification.

Section Two (normative) binds this particular profile to the OpenC2 Language Specification. Section Two enumerates the components of the language specification that are meaningful in the context of PF and defines components that are applicable to this distinct profile. Section Two also defines the Commands (i.e., the Action/Target pairs) that are permitted in the context of PF.

Section Three (normative) presents definitive criteria for conformance so that cyber security stakeholders can be assured that their products, instances and/or integrations are compatible with OpenC2.

Annex A (non-normative) provides multiple examples of Commands and associated Responses (JSON serialization) to facilitate development.

2 OpenC2 Language Binding

This section is normative

This section defines the set of Actions, Targets, Specifiers, and Arguments that are meaningful in the context of an PF. This section also describes the appropriate format for the status and properties of a Response frame. This section is organized into three major subsections; Command Components, Response Components and Commands.

Extensions to the Language Specification are defined in accordance with [OpenC2-Lang-v1.0], Section 3.1.5, where:

  1. The unique name of the PF schema is oasis-open.org/openc2/v1.0/ap-pf
  2. The namespace identifier (nsid) referring to the PF schema is: pf
  3. The definitions of and conformance requirements for these types are contained in this document

2.1 OpenC2 Command Components

The components of an OpenC2 Command include Actions, Targets, Actuators and associated Arguments and Specifiers. Appropriate aggregation of the components will define a Command-body that is meaningful in the context of an PF.

This specification identifies the applicable components of an OpenC2 Command. The components of an OpenC2 Command include:

2.1.1 Actions

Table 2.1.1-1 presents the OpenC2 Actions defined in Version 1.0 of the Language Specification which are meaningful in the context of an PF. The particular Action/Target pairs that are required or are optional are presented in Section 2.3.

Table 2.1.1-1. Actions Applicable to PF

Type: Action (Enumerated)

ID Name Description
3 query Initiate a request for information. Used to communicate the supported options and determine the state or settings
6 deny Prevent traffic or access
8 allow Permit traffic or access
16 update Instructs the Actuator to update its configuration by retrieving and processing a configuration file and update
20 delete Remove an access rule

2.1.2 Targets

Table 2.1.2-1 summarizes the Targets defined in Version 1.0 of the [OpenC2-Lang-v1.0] as they relate to PF functionality. Table 2.1.2-2 summarizes the Targets that are defined in this specification.

2.1.2.1 Common Targets

Table 2.1.2-1 lists the Targets defined in the OpenC2 Language Specification that are applicable to PF. The particular Action/Target pairs that are required or are optional are presented in Section 2.3.

Table 2.1.2-1. Targets Applicable to PF

Type: Target (Choice)

ID Name Type Description
9 features Features A set of items such as Action/Target pairs, profiles versions, options that are supported by the Actuator. The Target is used with the query Action to determine an Actuator's capabilities
10 file File Properties of a file
13 ipv4_net IPv4-Net The representation of one or more IPv4 addresses expressed using CIDR notation
14 ipv6_net IPv6-Net The representation of one or more IPv6 addresses expressed using CIDR notation
15 ipv4_connection IPv4-Connection A network connection as specified by a five-tuple (IPv4)
16 ipv6_connection IPv6-Connection A network connection as specified by a five-tuple (IPv6)
17 domain_name Domain-Name A domain name as defined in [RFC1034]

The semantics/ requirements as they pertain to common targets:

2.1.2.2 PF Targets

The list of common Targets is extended to include the additional Targets defined in this section and referenced with the pf namespace.

Table 2.1.2-2. Targets Unique to PF

Type: Target (Choice)

ID Name Type Description
1024 rule_number Rule-ID Immutable identifier assigned when a rule is created. Identifies a rule to be deleted
1025 advanced_connection Array An advanced connection MUST be a seven tuple intended to support newer and more advanced packet filters. See description below

2.1.3 Command Arguments

Arguments provide additional precision to a Command by including information such as how, when, or where a Command is to be executed. Table 2.1.3-1 summarizes the Command Arguments defined in Version 1.0 of the [OpenC2-Lang-v1.0] as they relate to PF functionality. Table 2.1.3-2 summarizes the Command Arguments that are defined in this specification.

2.1.3.1 Common Arguments

Table 2.1.3-1 lists the Command Arguments defined in the [OpenC2-Lang-v1.0] that are applicable to PF.

Table 2.1.3-1. Command Arguments applicable to PF

Type: Args (Map)

ID Name Type # Description
1 start_time Date-Time 0..1 The specific date/time to initiate the Action
2 stop_time Date-Time 0..1 The specific date/time to terminate the Action
3 duration Duration 0..1 The length of time for an Action to be in effect
4 response_requested Response-Type 0..1 The type of Response required for the Action: none, ack, status, complete

2.1.3.2 PF Arguments

The list of common Command Arguments is extended to include the additional Command Arguments defined in this section and referenced with the pf namespace.

Table 2.1.3-2. Command Arguments Unique to PF

Type: Args (Map)

ID Name Type # Description
1024 drop_process Drop-Process 0..1 Specifies how to handle denied packets
1025 persistent Boolean 0..1 Normal operations assume any changes to a device are to be implemented persistently. Setting the persistent modifier to FALSE results in a change that is not persistent in the event of a reboot or restart
1026 direction Direction 0..1 Specifies whether to apply rules to incoming or outgoing traffic. If omitted, rules are applied to ingress packets
1027 insert_rule Rule-ID 0..1 Specifies the identifier of the rule within a list, typically used in a top-down rule list
1028 logged Boolean 0..1 Specifies if a log entry should be recorded as traffic matches the rule. The manner and mechanism for recording these entries is implementation specific and not defined by this specification.
1029 description String 0..1 A note to annotate or provide information regarding the rule
1030 stateful Boolean 0..1 Specifies if the actuator should treat the request using state tables or connection state when set to TRUE
1031 priority Integer 0..1 Specifies the location of a specific firewall rule for firewalls that assign a numeric priority used to determine which firewall rule takes precedence

Note that if stateful is not explicitly set and the actuator only operates in either stateful or stateless the command would apply as if this argument was appropriately specified (e.g. stateful for Google Cloud Platform). If the actuator supports both mechanisms and this argument is not set, then it should treat the command as if the argument was set to stateless in order to be backwards compatible with the slpf.

Type: Drop-Process (Enumerated)

ID Name Description
1 none Drop the packet and do not send a notification to the source of the packet
2 reject Drop the packet and send an ICMP host unreachable (or equivalent) to the source of the packet
3 false_ack Drop the traffic and send a false acknowledgment

Type: Direction (Enumerated)

ID Name Description
1 both Apply rules to all traffic
2 ingress Apply rules to incoming traffic only
3 egress Apply rules to outgoing traffic only

Note that direction is required by some packet filters. For a host-based or host interface-based packet filter, ingress indicates a packet that originated from a different host. For a network-based packet filter, such as a router or a switch, ingress indicates a packet entering a physical or logical interface that your organization controls.

packet directions

Type: Rule-ID

Type Name Type Description
Rule-ID Integer Access rule identifier

The semantics/requirements as they relate to PF arguments:

2.1.4 Actuator Specifiers

An Actuator is the entity that provides the functionality and performs the Action. The Actuator executes the Action on the Target. In the context of this profile, the Actuator is the PF and the presence of one or more Specifiers further refine which Actuator(s) shall execute the Action.

Table 2.1.4-1 lists the Specifiers that are applicable to the PF Actuator. Annex A provides sample Commands with the use of Specifiers.

The Actuator Specifiers defined in this document are referenced under the pf namespace.

Table 2.1.4-1. PF Specifiers

Type: Specifiers (Map)

ID Name Type # Description
1 hostname String 0..1 [RFC1123] hostname (can be a domain name or IP address) for a particular device with PF functionality
2 named_group String 0..1 User defined collection of devices with PF functionality
3 asset_id String 0..1 Unique identifier for a particular PF
4 asset_tuple String 0..10 Unique tuple identifier for a particular PF consisting of a list of up to 10 strings

2.2 OpenC2 Response Components

Response messages originate from the Actuator as a result of a Command.

Responses associated with required Actions MUST be implemented. Implementations that include optional Actions MUST implement the RESPONSE associated with the implemented Action. Additional details regarding the Command and associated Response are captured in Section 2.3. Examples are provided in Annex A.

2.2.1 Common Results

Table 2.2.1-1 lists the Response Results properties defined in the [OpenC2-Lang-v1.0] that are applicable to PF.

Table 2.2.1-1. Response Results Applicable to PF

Type: Results (Map [1..*])

ID Name Type # Description
1 versions Version 0..* List of OpenC2 language versions supported by this Actuator
2 profiles ArrayOf(Nsid) 0..1 List of profiles supported by this Actuator
3 pairs Action-Targets 0..* List of targets applicable to each supported Action
4 rate_limit Number 0..1 Maximum number of requests per minute supported by design or policy

2.2.2 PF Results

The list of common Response properties is extended to include the additional Response properties defined in this section and referenced with the pf namespace.

Table 2.2.2-1. PF Results

Type: OpenC2-Response (Map)

ID Name Type Description
1024 rule_number Rule-ID Rule identifier returned from allow or deny Command

2.2.3 Response Status Codes

Table 2.2.1-2 lists the Response Status Codes defined in the OpenC2 Language Specification that are applicable to PF.

Table 2.2.1-2. Response Status Codes

Type: Status-Code (Enumerated.ID)

Value Description
102 Processing. Command received but action not necessarily complete.
200 OK.
400 Bad Request. Unable to process Command, parsing error.
500 Internal Error. For "response_requested" value "complete", one of the following MAY apply:
* Cannot access file or path
* Rule number currently in use
* Rule not updated
501 Not implemented. For "response_requested" value "complete", one of the following MAY apply:
* Target not supported
* Option not supported
* Command not supported

2.3 OpenC2 Commands

An OpenC2 Command consists of an Action/Target pair and associated Specifiers and Arguments. This section enumerates the allowed Commands and presents the associated Responses.

Table 2.3-1 defines the Commands that are valid in the context of the PF profile. An Action (the top row in Table 2.3-1) paired with a Target (the first column in Table 2.3-1) defines a valid Command. The subsequent subsections provide the property tables applicable to each OpenC2 Command.

Table 2.3-1. Command Matrix

Allow Deny Query Delete Update
ipv4_connection valid valid
ipv6_connection valid valid
ipv4_net valid valid
ipv6_net valid valid
pf:advanced_connection valid valid
domain_name valid valid
features valid
pf:rule_number valid valid
file valid

Table 2.3-2 defines the Command Arguments that are allowed for a particular Command by the PF profile. A Command (the top row in Table 2.3-2) paired with an Argument (the first column in Table 2.3-2) defines an allowable combination. The subsection identified at the intersection of the Command/Argument provides details applicable to each Command as influenced by the Argument.

Table 2.3-2. Command Arguments Matrix

Allow target Deny target Query features Query pf:rule_number Delete pf:rule_number Update file
response_requested 2.3.1 2.3.2 2.3.3.1 2.3.4.1 2.3.5.1
start_time 2.3.1 2.3.2 2.3.4.1 2.3.5.1
stop_time 2.3.1 2.3.2
duration 2.3.1 2.3.2
persistent 2.3.1 2.3.2
direction 2.3.1 2.3.2
insert_rule 2.3.1 2.3.2
drop_process 2.3.2
logged 2.3.1 2.3.2
stateful 2.3.1 2.3.2
priority 2.3.1 2.3.2

2.3.1 Allow

Table 2.3-2 summarizes the Command Arguments that apply to all of the Commands consisting of the 'allow' Action and a valid Target type.

Upon receipt of an unsupported Command Argument, PF Consumers

OpenC2 Producers that send 'allow target' Commands and support the 'delete pf:rule_number' Command:

OpenC2 Consumers that receive and successfully parse 'allow ' Commands but cannot implement the 'allow ' :

OpenC2 Consumers that receive 'allow ' Commands and support the 'delete pf:rule_number' Command:

OpenC2 Consumers that receive 'allow target' Commands and support the 'insert_rule' Command Argument:

The valid Target types, associated Specifiers, and Options are summarized in Section 2.3.1.1 and Section 2.3.1.2. Sample Commands are presented in Annex A.

2.3.1.1 'Allow ipv4_connection'

The 'allow ipv4_connection' Command is OPTIONAL for Openc2 Producers implementing the PF. The 'allow ipv4_connection' Command is OPTIONAL for Openc2 Consumers implementing the PF.

The Command permits traffic that is consistent with the specified ipv4_connection. A valid 'allow ipv4_connection' Command has at least one property of the ipv4_connection populated and may have any combination of the five properties populated. An unpopulated property within the ipv4_connection Target MUST be treated as an 'any'.

Products that receive but do not implement the 'allow ipv4_connection' Command:

2.3.1.2 'Allow ipv6_connection'

The 'allow ipv6_connection' Command is OPTIONAL for Openc2 Producers implementing the PF. The 'allow ipv6_connection' Command is OPTIONAL for Openc2 Consumers implementing the PF.

The Command permits traffic that is consistent with the specified ipv6_connection. A valid 'allow ipv6_connection' Command has at least one property of the ipv6_connection populated and may have any combination of the five properties populated. An unpopulated property within the the ipv4_connection Target MUST be treated as an 'any'.

Products that receive but do not implement the 'allow ipv6_connection' Command:

2.3.1.3 'Allow ipv4_net'

The 'allow ipv4_net' Command is OPTIONAL for Openc2 Producers implementing the PF. The 'allow ipv4_net' Command is OPTIONAL for Openc2 Consumers implementing the PF.

The Command permits traffic as specified by the range of IPv4 addresses as expressed by CIDR notation. If the mask is absent (or unspecified) then it MUST be treated as a single IPv4 address (i.e., an address range of one element). The address range specified in the ipv4_net MUST be treated as a source OR destination address.

Products that receive but do not implement the 'allow ipv4_net' Command:

2.3.1.4 'Allow ipv6_net'

The 'allow ipv6_net' Command is OPTIONAL for Openc2 Producers implementing the PF. The 'allow ipv6_net' Command is OPTIONAL for Openc2 Consumers implementing the PF.

The Command permits traffic as specified by the range of IPv6 addresses as expressed by CIDR notation. If the mask is absent (or unspecified) then it MUST be treated as a single IPv6 address (i.e., an address range of one element). The address range specified in the ipv6_net MUST be treated as a source OR destination address.

Products that receive but do not implement the 'allow ipv6_net' Command:

2.3.1.5 'Allow domain_name'

The 'allow domain_name' Command is OPTIONAL for Openc2 Producers implementing the PF. The 'allow domain_name' Command is OPTIONAL for Openc2 Consumers implementing the PF.

The Command permits traffic that is consistent with the specified domain name.

Products that receive but do not implement the 'allow domain_name' Command:

2.3.2 Deny

'Deny' can be treated as the mathematical complement to 'allow'. With the exception of the additional 'drop_process' Actuator-Argument, the Targets, Specifiers, Options and corresponding Responses are identical to the four 'allow' Commands. Table 2.3-2 summarizes the Command Arguments that apply to all of the Commands consisting of the 'deny' Action and valid Target type.

Upon receipt of a Command with an Argument that is not supported by the Actuator:

OpenC2 Producers that send 'deny target' Commands and support the 'delete pf:rule_number' Command:

OpenC2 Consumers that receive 'deny ' Commands and support the 'delete pf:rule_number' Command:

OpenC2 Consumers that receive 'deny target' Commands and support the 'insert_rule' Command Argument:

2.3.3 Query

The valid Target type, associated Specifiers, and Options are summarized in Section 2.3.3.1. Sample Commands are presented in Annex A.

2.3.3.1 Query features

The 'query features' Command MUST be implemented in accordance with Version 1.0 of the [OpenC2-Lang-v1.0].

2.3.3.1 Query pf:rule_number

The 'query pf:rule_number' Command provides a mechanism to obtain similar information to that provided by creating a firewall rule Implementation of the 'query pf:rule_number' Command is OPTIONAL. Products that choose to implement the 'delete pf:rule_number' Command MUST implement the pf:rule_number Target type described in Section 2.1.2.2.

2.3.4 Delete

The pf:rule_number is the only valid Target type for the delete Action. The associated Specifiers, and Options are summarized in Section 2.3.4.1. Sample Commands are presented in Annex A.

2.3.4.1 delete pf:rule_number

The 'delete pf:rule_number' Command is used to remove a firewall rule rather than issue an allow or deny to counteract the effect of an existing rule. Implementation of the 'delete pf:rule_number' Command is OPTIONAL. Products that choose to implement the 'delete pf:rule_number' Command MUST implement the pf:rule_number Target type described in Section 2.1.2.2.

OpenC2 Producers that send the 'delete pf:rule_number' Command:

OpenC2 Consumers that receive the 'delete pf:rule_number' Command:

Refer to Annex A for sample Commands.

2.3.5 Update

The 'file' Target as defined in Version 1.0 of the Language Specification is the only valid Target type for the update Action. The associated Specifiers, and Options are summarized in Section 2.3.5.1. Sample Commands are presented in Annex A.

2.3.5.1 Update file

The 'update file' Command is used to replace or update files such as configuration files, rule sets, etc. Implementation of the update file Command is OPTIONAL. OpenC2 Consumers that choose to implement the 'update file' Command MUST include all steps that are required for the update file procedure such as retrieving the file(s), install the file(s), restart/ reboot the device etc. The end state shall be that the firewall operates with the new file at the conclusion of the 'update file' Command. The atomic steps that take place are implementation specific.

Table 2.3-2 presents the valid options for the 'update file' Command. OpenC2 Producers and Consumers that choose to implement the 'update file' Command MUST NOT include options other than the options identified in Table 2.3-2.

OpenC2 Producers that send the 'update file' Command:

OpenC2 Consumers that receive the 'update file' Command:

Refer to Annex A for sample Commands.

3 Conformance statements

This section is normative This section identifies the requirements for twenty-two conformance profiles as they pertain to two conformance targets. The two conformance targets are OpenC2 Producers and OpenC2 Consumers (as defined in Section 1.8 of this specification).

3.1 Clauses Pertaining to the OpenC2 Producer Conformance Target

All OpenC2 Producers that are conformant to this specification MUST satisfy Conformance Clause 1 and MAY satisfy one or more of Conformance Clauses 2 through 11.

3.1.1 Conformance Clause 1: Baseline OpenC2 Producer

An OpenC2 Producer satisfies Baseline OpenC2 Producer conformance if:

3.1.2 Conformance Clause 2: IP Version 4 Connection Producer

An OpenC2 Producer satisfies 'IP Version 4 Connection Producer' conformance if:

3.1.3 Conformance Clause 3: IP Version 6 Connection Producer

An OpenC2 Producer satisfies 'IP Version 6 Connection Producer' conformance if:

3.1.4 Conformance Clause 4: IP Version 4 Net Producer

An OpenC2 Producer satisfies 'IP Version 4 Net Producer' conformance if:

3.1.5 Conformance Clause 5: IP Version 6 Net Producer

An OpenC2 Producer satisfies 'IP Version 6 Net Producer' conformance if:

3.1.6 Conformance Clause 6: Domain Name Producer

An OpenC2 Producer satisfies 'Domain Name Producer' conformance if:

3.1.7 Conformance Clause 7: Update File Producer

An OpenC2 Producer satisfies 'Update File Producer' conformance if:

3.1.8 Conformance Clause 8: delete rule number Producer

An OpenC2 Producer satisfies 'delete rule Producer' conformance if:

3.1.9 Conformance Clause 9: Persistent Producer

An OpenC2 Producer satisfies 'Persistent Producer' conformance if:

3.1.10 Conformance Clause 10: Direction Producer

An OpenC2 Producer satisfies 'Direction Producer' conformance if:

3.1.11 Conformance Clause 11: drop-process Producer

An OpenC2 Producer satisfies 'drop-process Producer' conformance if:

3.1.12 Conformance Clause 12: Temporal Producer

An OpenC2 Producer satisfies 'Temporal Producer' conformance if:

3.1.13 Conformance Clause 13: Logging Producer

An OpenC2 Producer satisfies 'Logging Producer' conformance if:

3.2 Clauses Pertaining to the OpenC2 Consumer Conformance Target

All OpenC2 Consumers that are conformant to this specification MUST satisfy Conformance Clause 12 and MAY satisfy one or more of Conformance Clauses 13 through 22.

3.2.1 Conformance Clause 12: Baseline OpenC2 Consumer

An OpenC2 Consumer satisfies Baseline OpenC2 Consumer conformance if:

3.2.2 Conformance Clause 13: IP Version 4 Connection Consumer

An OpenC2 Consumer satisfies 'IP Version 4 Connection Consumer' conformance if:

3.2.3 Conformance Clause 14: IP Version 6 Connection Consumer

An OpenC2 Consumer satisfies 'IP Version 6 Connection Consumer' conformance if:

3.2.4 Conformance Clause 15: IP Version 4 Net Consumer

An OpenC2 Consumer satisfies 'IP Version 4 Net Consumer' conformance if:

3.2.5 Conformance Clause 16: IP Version 6 Net Consumer

An OpenC2 Consumer satisfies 'IP Version 6 Net Consumer' conformance if:

3.2.6 Conformance Clause 17: Domain Name Consumer

An OpenC2 Consumer satisfies 'Domain Name Consumer' conformance if:

3.2.7 Conformance Clause 18: Update File Consumer

An OpenC2 Consumer satisfies 'Update File Consumer' conformance if:

3.2.8 Conformance Clause 19: delete rule number Consumer

An OpenC2 Consumer satisfies 'delete rule Consumer' conformance if:

3.2.9 Conformance Clause 20: Persistent Consumer

An OpenC2 Consumer satisfies 'Persistent Consumer' conformance if:

3.2.10 Conformance Clause 21: Direction Consumer

An OpenC2 Consumer satisfies 'Direction Consumer' conformance if:

3.2.11 Conformance Clause 22: drop-process Consumer

An OpenC2 Consumer satisfies 'drop-process Consumer' conformance if:

3.2.12 Conformance Clause 23: Temporal Consumer

An OpenC2 Consumer satisfies 'Temporal Consumer' conformance if:

3.2.13 Conformance Clause 24: Logging Consumer

An OpenC2 Consumer satisfies 'Logging Consumer' conformance if:

Appendix A. References

This appendix contains the normative and informative references that are used in this document.

While any hyperlinks included in this appendix were valid at the time of publication, OASIS cannot guarantee their long-term validity.

A.1 Normative References

The following documents are referenced in such a way that some or all of their content constitutes requirements of this document.

[RFC1034]

Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, https://www.rfc-editor.org/info/rfc1034.

[RFC1123]

Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, https://www.rfc-editor.org/info/rfc1123.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC2780]

Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, https://www.rfc-editor.org/info/rfc2780.

[RFC4443]

Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, https://www.rfc-editor.org/info/rfc4443.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, https://www.rfc-editor.org/info/rfc8259.

[OpenC2-Lang-v1.0]

Open Command and Control (OpenC2) Language Specification Version 1.0. Edited by Jason Romano and Duncan Sparrell. Latest stage: https://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html.

A.2 Informative References

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, https://www.rfc-editor.org/info/rfc3339.

[RFC4291]

Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, https://www.rfc-editor.org/info/rfc4291.

[RFC6891]

Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, https://www.rfc-editor.org/info/rfc6891.

[RFC5237]

Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the Protocol Field", BCP 37, RFC 5237, DOI 10.17487/RFC5237, February 2008, https://www.rfc-editor.org/info/rfc5237.

[OpenC2-HTTPS-v1.0]

Specification for Transfer of OpenC2 Messages via HTTPS Version 1.0. Edited by David Lemire. Latest stage: https://docs.oasis-open.org/openc2/open-impl-https/v1.0/open-impl-https-v1.0.html.

[ACD]

Herring, M.J. and Willett, K.D. "Active Cyber Defense: A Vision for Real-Time Cyber Defense," Journal of Information Warfare, vol. 13, Issue 2, p. 80, April 2014, https://www.semanticscholar.org/paper/Active-Cyber-Defense-%3A-A-Vision-for-Real-Time-Cyber-Herring-Willett/7c128468ae42584f282578b86439dbe9e8c904a8.

[IACD]

Willett, Keith D., "Integrated Adaptive Cyberspace Defense: Secure Orchestration", International Command and Control Research and Technology Symposium, June 2015 https://www.semanticscholar.org/paper/Integrated-Adaptive-Cyberspace-Defense-%3A-Secure-by-Willett/a22881b8a046e7eab11acf647d530c2a3b03b762.

Appendix B. Safety, Security and Privacy Considerations

Implementors should understand the topology that will be controlled and take steps to ensure the security of systems generating and accepting commands. The technical committee recommends taking steps such as enabling both Transport Layer Security and mutual authentication. Additionally, implementing consumer-side checks such as type enforcement and length are recommended.

Appendix C. Acknowledgments

C.1 Special Thanks

Substantial contributions to this document from the following individuals are gratefully acknowledged:

Duncan Sparrell David Lemire

C.2 Participants

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

OpenC2 TC Members:

First Name Last Name Company
Robert Roll Arizona Supreme Court
Michelle Barry AT&T
Blake Essing AT&T
Anthony Librera AT&T
Patrick Maroney AT&T
Dan Solero AT&T
Michael Stair AT&T
Bill Trost AT&T
Sean Welsh AT&T
Radu Marian Bank of America
Wende Peters Bank of America
Alexandre Dulaunoy CIRCL
Andras Iklody CIRCL
Omar Santos Cisco Systems
Sam Taghavi Zargar Cisco Systems
Jyoti Verma Cisco Systems
Tim Hudson Cryptsoft Pty Ltd.
Ryan Joyce DarkLight, Inc.
Paul Patrick DarkLight, Inc.
Juan Gonzalez DHS Office of Cybersecurity and Communications (CS&C)
Raymon van der Velde EclecticIQ
Ben Sooter Electric Power Research Institute (EPRI)
Chris Ricard Financial Services Information Sharing and Analysis Center (FS-ISAC)
Gerald Stueve Fornetix
Charles White Fornetix
Ryusuke Masuoka Fujitsu Limited
Koji Yamada Fujitsu Limited
Jason Callaway Google Inc.
David Webber Huawei Technologies Co., Ltd.
Stephanie Hazlewood IBM
Emily Ratliff IBM
Michele Drgon Individual
Joerg Eschweiler Individual
Terry MacDonald Individual
Anthony Rutkowski Individual
Himanshu Kesar LookingGlass
Paolo Zaino LookingGlass
Sudeep Das McAfee
Kent Landfield McAfee
Jonathan Baker Mitre Corporation
Joe Brule National Security Agency
Jessica Fitzgerald-McKay National Security Agency
Zachary Gorak National Security Agency
David Kemp National Security Agency
David Lemire National Security Agency
Michael Rosa National Security Agency
Daichi Hasumi NEC Corporation
Takahiro Kakumaru NEC Corporation
Lauri Korts-Pärn NEC Corporation
John-Mark Gurney New Context Services, Inc.
Christian Hunt New Context Services, Inc.
Daniel Riedel New Context Services, Inc.
Andrew Storms New Context Services, Inc.
Drew Varner NineFX, Inc.
Stephen Banghart NIST
David Waltermire NIST
James Crossland Northrop Grumman
Jason Liu Northrop Grumman
Duane Skeen Northrop Grumman
Calvin Smith Northrop Grumman
Cheolho Lee NSR
David Bizeul SEKOIA
Dan Johnson sFractal Consulting LLC
Duncan Sparrell sFractal Consulting LLC
Marco Caselli Siemens AG
Tom Maier Siemens AG
Andrew Pendergast ThreatConnect, Inc.
Joe Reese ThreatConnect, Inc.
Ryan Trost ThreatQuotient, Inc.
David Girard Trend Micro
Shoko Honda Trend Micro
Takayuki Tachihara Trend Micro
Toby Considine University of North Carolina at Chapel Hill
Alex Everett University of North Carolina at Chapel Hill
Martin Evandt University of Oslo
Vasileios Mavroeidis University of Oslo
Aleksandra Scalco US Department of Defense (DoD)
Randall Sharo US Department of Defense

Appendix D. Revision History

Revision Date Editor Changes Made
openc2-ap-pf-v1.0-wd01 2021-05-03 Alex Everett Initial working draft

Appendix E. Sample Commands

This section is non-normative

This section will summarize and provide examples of OpenC2 Commands as they pertain to packet filters. The sample Commands will be encoded in verbose JSON, however other encodings are possible provided the Command is validated against the property tables defined in Section 2 of this specification. Examples of corresponding Responses are provided where appropriate.

The samples provided in this section are for illustrative purposes only and are not to be interpreted as operational examples for actual systems.

The following examples include Binary fields which are encoded in Base64url format. The examples show JSON-serialized Commands; the conversion of Base64url values to Binary data and String display text is:

Base64url Binary Display String
AQIDBA 01020304 1.2.3.4
xgIDBA c6020304 198.2.3.4
xjNkEQ c6336411 198.51.100.17

The examples include Integer Date-Time fields; the conversion of Integer values to String display text is:

Integer Display String
1534775460000 Monday, August 20, 2018 2:31:00 PM GMT, 2018-08-20T10:31:00-04:00

=======

E.1 Deny and Allow

Deny and allow can be treated as mathematical complements of each other. Unless otherwise stated, the example Targets, Specifiers, Arguments and corresponding Responses are applicable to both Actions.

E.1.1 Deny a particular connection

Block a particular connection within the domain and do not send a host unreachable. Note, the "pf":{"drop_process"} argument does not apply to the allow Action.

Command:

{
  "action": "deny",
  "target": {
    "ipv4_connection": {
      "protocol": "tcp",
      "src_addr": "1.2.3.4",
      "src_port": 10996,
      "dst_addr": "198.2.3.4",
      "dst_port": 80
    }
  },
  "args": {
    "start_time": 1534775460000,
    "duration": 500,
    "response_requested": "ack",
    "pf": {
       "drop_process": "none"
       }
  },
  "actuator": {
        "pf": {
            "asset_id": "30"
        }
    }
}

Response:

{
  "status": 102
}

E.1.2 Deny all outbound ftp transfers

Block all outbound ftp data transfers, send false acknowledgment. Note that the five-tuple is incomplete. Note that the response_requested field was not populated therefore will be 'complete'. Also note that the Actuator called out was PF with no additional Specifiers, therefore all endpoints that can execute the Command should. Note, the "pf":{"drop_process"} argument does not apply to the allow Action.

Command:

{
  "action": "deny",
  "target": {
    "ipv4_connection": {
      "protocol": "tcp",
      "src_port": 21
    }
  },
  "args": {
    "pf": {
      "drop_process": "false_ack",
      "direction": "egress"
    }
  },
  "actuator": {
    "pf": {}
  }
}

Responses:

Case One: the Actuator successfully issued the deny.

{
  "status": 200
}

Case Two: the Command failed due to a syntax error in the Command. Optional status text is ignored by the Producer, but may be added to provide error details for debugging or logging.

{
  "status": 400,
  "status_text": "Validation Error: Target: ip_conection"
}

Case Three: the Command failed because an Argument was not supported.

{
  "status": 501
}

E.1.3 Block all inbound traffic from a particular source.

Block all inbound traffic from the specified ipv6 network and do not respond. In this case the ipv6_net Target and the direction argument was used. In this case only the perimeter filters should update the rule.

Command:

{
  "action": "deny",
  "target": {
    "ipv6_net": "3ffe:1900:4545:3:200:f8ff:fe21:67cf"
  },
  "args": {
    "response_requested": "none",
    "pf": {
      "direction": "ingress"
    }
  },
  "actuator": {
    "pf": {
      "named_group": "perimeter"
    }
  }
}

E.1.4 Statefully permit ftp transfers to a particular destination.

Permit ftp data transfers to 3ffe:1900:4545:3::f8ff:fe21:67cf from any initiating source and allow needed return traffic. (Note that an actual application may also need to allow ftp-data (port 20) in order for transfers to be permitted depending on the ftp connection type and the firewall technology).

Command:

{
  "action": "allow",
  "target": {
    "ipv6_connection": {
      "protocol": "tcp",
      "dst_addr": "3ffe:1900:4545:3::f8ff:fe21:67cf",
      "src_port": 21
    }
  },
  "actuator": {
    "pf": {
       "stateful": true
    }
  }
}

In this case the Actuator returned a rule number associated with the allow.

Response:

{
  "status": 200,
  "results": {
    "pf": {
      "rule_number": 1234
    }
  }
}

E.2 Delete Rule

Used to remove a firewall rule rather than issue an allow or deny to counteract the effect of an existing rule. Implementation of the 'delete pf:rule_number' Command is OPTIONAL.

In this case the rule number assigned in a previous allow will be removed (refer to the final example in Annex A.1

Command:

{
  "action": "delete",
  "target": {
    "pf:rule_number": 1234
  },
  "args": {
    "response_requested": "complete"
  },
  "actuator": {
    "pf": {}
  }
}

E.3 Update file

Implementation of the Update Action is optional. Update is intended for the device to process new configuration files. The update Action is a compound Action in that all of the steps required for a successful update (such as download the new file, install the file, reboot etc.) are implied. File is the only valid Target type for Update.

Instructs the firewalls to acquire a new configuration file. Note that all network based firewalls will install the new update because no particular firewall was identified. Host based firewalls will not act on this because network firewalls were identified as the Actuator.

Command:

{
  "action": "update",
  "target": {
    "file": {
      "path": "\\\\someshared-drive\\somedirectory\\configurations",
      "name": "firewallconfiguration.txt"
    }
  },
  "actuator": {
    "pf": {
      "named_group": "network"
    }
  }
}

Responses:

Successful update of the configuration

{
  "status": 200
}

This Actuator does not support the update file Command

{
  "status": 501,
  "status_text": "Update-File Not Implemented"
}

This Actuator could not access the file

{
  "status": 500,
  "status_text": "Server error, Cannot access file"
}

E.4 Query features

Implementation of query Openc2 is required. The query features Command is intended to enable the Openc2 Producer to determine the capabilities of the Actuator. The query features Command can also be used to check the status of the Actuator.

E.4.1 No query items set

This Command uses query features with no query items to verify that the Actuator is functioning.

Command:

{
  "action": "query",
  "target": {
    "features": []
  }
}

Response:

The Actuator is alive.

{
  "status": 200
}

E.4.2 Version of Language specification supported

This Command queries the Actuator to determine which version(s) of the language specification are supported. The language specifications use semantic versioning ("major.minor"); for each supported major version the Actuator need only report the highest supported minor version.

Command:

{
    "action": "query",
    "target": {
        "features": ["versions"]
    }
}

Response:

The Actuator supports language specification version 1.0.

{
    "status": 200,
    "results": {
        "versions": ["1.0"]
    }
}

E.4.3 Actuator profiles supported

This Command queries the Actuator to determine both the language versions and the profiles supported.

Command:

{
  "action": "query",
  "target": {
    "features": ["versions", "profiles"]
  }
}

Response:

The Actuator device is apparently a smart front-door-lock for which an extension profile has been written. The device supports both the standard pf functions and whatever Commands are defined in the extension profile.

{
  "status": 200,
  "results": {
    "versions": ["1.3"],
    "profiles": ["pf", "iot-front-door-lock"]
  }
}

E.4.4 Specific Commands Supported

This Command queries the Actuator to determine which Action/Target pairs are supported. Not all Targets are meaningful in the context of a specific Action, and although a Command such as "update ipv4_connection" may be syntactically valid, the combination does not specify an operation supported by the Actuator.

Command:

For each supported Action list the Targets supported by this Actuator.

{
  "action": "query",
  "target": {
    "features": ["pairs"]
  }
}

Response:

The Actuator supports all Action/Target pairs shown in Table 2.3-1 - Command Matrix.

{
  "status": 200,
  "results": {
    "pairs": {
      "allow": ["ipv6_net", "ipv6_connection"],
      "deny": ["ipv6_net", "ipv6_connection"],
      "query": ["features"],
      "delete": ["pf:rule_number"],
      "update": ["file"]
    }
  }
}

E.4.5 Rule Details

This Command queries the Actuator to determine the Target and Argument values for a particular rule.

Command:

For each supported Action list the Targets supported by this Actuator.

{
  "action": "query",
  "target": {
    "pf:rule_number": 20
  }
  "actuator": {
    "pf": {
     "asset_id": "30"
    }
  }
}

Response:

The Actuator returns information that could be used to reconstruct the rule.

{
  "status": 200,
  "results": {
    "pf": {
      "rule_number": 20,
      "ipv4_connection": {
      "protocol": "tcp",
      "src_addr": "1.2.3.4",
      "src_port": 10996,
      "dst_addr": "198.2.3.4",
      "dst_port": 80
    }
    "args": {
      "drop_process": "false_ack",
      "direction": "egress"
    }
    }
  }
}

Appendix F. Notices

Copyright © OASIS Open 2021. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

As stated in the OASIS IPR Policy, the following three paragraphs in brackets apply to OASIS Standards Final Deliverable documents (Committee Specification, Candidate OASIS Standard, OASIS Standard, or Approved Errata).

[OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this deliverable.]

[OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this OASIS Standards Final Deliverable. OASIS may include such claims on its website, but disclaims any obligation to do so.]

[OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.