Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand brian.e.carpenter@gmail.com

Huawei Technologies Co., Ltd

Q22, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China leo.liubing@huawei.com

This document defines the formats of several technical objectives for the Generic Autonomic Signaling Protocol (GRASP) used by components of the Autonomic Networking Infrastructure outlined in the ANIMA reference model. It also covers other initial use cases for Autonomic Networking.

This document defines several technical objectives for use with for the Generic Autonomic Signaling Protocol (GRASP) . They are intended for use by corresponding Autonomic Service Agents (ASAs) that support infrastructure components of the Autonomic Network Infrastructure (ANI) outlined in the ANIMA reference model . Also other early use cases are in scope. Note: This draft is posted to allow systematic discussion of the various objectives in a consistent way. It is quite probable that rather than this being published as an RFC, the various objective definitions will be incorporated directly in the relevant specifications. The reference model identifies several infrastructure components that will fit together to form the ANI, and other early use cases for ANIMA are also considered: Secure Bootstrap. Autonomic Control Plane (ACP). Stable Connectivity of Network OAM. Intent Distribution. Prefix Management The following sections define GRASP objectives for each of these cases. They are described in an informal object notation and formally using CBOR data definition language (CDDL) . Undefined CDDL terms are defined in .

Three ANI components are involved in the Bootstrapping Remote Secure Key Infrastructures (BRSKI) process described in : the Join Registrar, the Join Assistant (or Proxy), and the Pledge (or Joining Node). In the present document we only consider interactions between autonomic nodes involved in BRSKI; non-autonomic nodes are expected to use different methods not involving GRASP. Note that since secure bootstrap takes place, by definition, on an incompletely secure network, the use of any protocol needs to be kept as simple and limited as possible. Therefore, only one GRASP message type is used - flooding - to avoid giving away any unnecessary information by any node involved. Operationally, the most simple case is when proxy and pledge have a link-local connection between them. In this case, mutual discovery and bootstrap can happen without any prior provisioning of helper information by an external mechanism. Instead, link-local multicast with GRASP can and will be used. This will minimize exposure to eavesdroppers and malicious nodes. On the other hand, there may be multiple physical hops between the proxy and the registrar. Therefore, two different GRASP objectives are required: one that is used over an existing secure network (typically the ACP) between the registrar and the proxy, and another that is used over an insecure link-local hop between the proxy and the pledge. The security aspects and the corresponding limited instances of GRASP are discussed in and .

A registrar announces itself to potential proxies by use of the "AN_join_registrar" objective. This is a synchronization objective primarily intended to be flooded throughout the network using the GRASP Flood Synchronization (M_FLOOD) message. In accordance with the design of the Flood message, a locator consisting of a specific IP address, IP protocol number and port number will be distributed with the flooded objective. An example of the objective is informally: ["AN_join_registrar", F_SYNCH, 5, [7, ["BRSKI-TLS"]]] The formal CDDL definition is

The 'max-hops' parameter allows a proxy that receives this message to determine its distance in hops from the registrar, by subtracting the received 'loop-count' from 'max-hops'. (Note: it is an open issue whether to include this parameter. Its value would be to allow a proxy to choose the nearest of several registrars.) The 'method' parameter indicates the specific BRSKI method(s) available at the given locator. The initial possible values are "BRSKI-TLS" and "BRSKI-COAP". A registrar that supports one method per locator may flood multiple versions of the "AN_join_registrar" objective. A different objective can be flooded for each method to support the case where independent ASAs are providing the registrar function for different methods, or to support the case where different locators support each method. For example, BRSKI-COAP would most likely be focussed to help enrol non-autonomic pledges and could have a range of aspects that would make implementation in a separate ASA beneficial (e.g., different scale/policies for non-autonomic pledges). Alternatively, several methods supported by a single registrar at a single locator can be flooded as a single objective.

This alternative usage of "AN_join_registrar" uses additional features of GRASP. It requires additional complexity in the Join Assistant, and causes it to announce its existence to any eavesdroppers in the autonomic network via a multicast Discovery message. It must therefore only be used when GRASP is running securely, typically because the Join Assistant is in a node that has already joined the ACP. A Join Assistant discovers a Join Registrar and negotiates a BRSKI method with it by use of the "AN_join_registrar" objective. First, the pledge performs GRASP discovery. If multiple responses occur, it chooses one by an implementation-defined method. Then the pledge initiates GRASP negotiation to choose a mutually acceptable BRSKI method. An example of the objective is informally: ["AN_join_registrar", F_NEG, 6, ["BRSKI-COAP","BRSKI-TLS"]] The formal CDDL definition is:

The parties will negotiate until one side proposes a single BRSKI method and the other side accepts. In the simplest case of immediate acceptance, there will only be two messages (Request Negotiate and End Negotiate). The locator (IP address, IP protocol number, port number) used for the negotiation will be available for the subsequent BRSKI operations, if required.

A Join Assistant announces itself to potential pledges by use of the "AN_join_assistant" objective. This is a synchronization objective primarily intended to be flooded on a single link using the GRASP Flood Synchronization (M_FLOOD) message. In accordance with the design of the Flood message, a locator consisting of a specific link-local IP address, IP protocol number and port number will be distributed with the flooded objective. An example of the objective is informally: ["AN_join_assistant", F_SYNCH, 1, "BRSKI-TLS"] The formal CDDL definition is:

The loop-count is fixed at 1 since this is a link-local operation. The 'method' parameter indicates the specific BRSKI method available at the given locator. The initial possible values are "BRSKI-TLS" and "BRSKI-COAP". A Join Assistant that supports more than one method will flood multiple versions of the "AN_join_assistant" objective.

The Autonomic Control Plane (ACP) constructs itself without outside intervention. To achieve this, each node needs to identify its link-local neighbors on all interfaces, and agree on a secure connection method with each of them. There are at least two possible approaches for this: a flooding mechanism, in which each node announces itself and it security methods to its neighbors, or a discovery and negotiation mechanism, in which each node actively discovers its neighbors. For the moment this draft describes both methods. For either method, each node runs an ASA that supports the corresponding objective. This ASA permanently, as long as the node is capable of being part of the ACP, in order to discover or detect new ACP neighbors or to remove failed neighbors.

A node announces itself to potential ACP peers by use of the "AN_ACP" objective. This is a synchronization objective primarily intended to be flooded on a single link using the GRASP Flood Synchronization (M_FLOOD) message. In accordance with the design of the Flood message, a locator consisting of a specific link-local IP address, IP protocol number and port number will be distributed with the flooded objective. An example of the objective is informally: ["AN_ACP", F_SYNCH, 1, ["IKEv2","TLS"] The formal CDDL definition is:

The loop-count is fixed at 1 since this is a link-local operation. The 'method' parameter indicates the specific connection method available at the given locator. The initial possible values are "IKEv2", "GRE-IKEv2", "TLS" and "dTLS". A node that supports more than one method per locator may flood multiple versions of the "AN_ACP" objective. Note that a node serving both as an ACP node and BRSKI Join Assistant may choose to distribute the "AN_ACP" objective and "AN_join_assistant" objective in the same message, since GRASP allows multiple objectives in one Flood message.

Each node discovers its neighbours and negotiates a connection method with each one by use of the "AN_ACP" objective. First, the node performs GRASP discovery, with the loop-count set to 1 and limited to link-local addresses. It records each response that it receives within the chosen discovery timeout. Then the pledge initiates GRASP negotiation with each newly discovered peer in turn to choose a mutually acceptable connection method. An example of the objective is informally: ["AN_ACP", F_NEG, 6, ["IKEv2","dTLS"]] The formal CDDL definition is:

The parties will negotiate until one side proposes a single connection method and the other side accepts. In the simplest case of immediate acceptance, there will only be two messages (Request Negotiate and End Negotiate). The locator (IP address, IP protocol number, port number) used for the negotiation will be available for the subsequent operations, if required. Note that in the Discovery message, the loop count will be set to 1 to limit discovery to the local link. In the negotiation stage, the loop count will serve its normal purpose (limiting the negotiation to 6 steps in the above example).

For OAM purposes , a special-purpose ASA, which we will call the NOC ASA, mediates connectivity between NOC systems performing OAM operations and autonomic nodes that can be reached securely via the ACP. This requires a discovery operation, which could be handled in two ways: the NOC ASA discovers all nodes, or each node discovers the NOC ASA. The latter seems much more practical. However, the NOC will need to know something about each target node, so the corresponding objective is defined as a negotiation objective to allow for this. An example of the objective is informally: ["AN_NOC", F_NEG, 6, [TBD]] The formal CDDL definition is:

When a node joins the ACP, one of its initial actions must be to perform GRASP discovery for "AN_NOC" and then to send a Request Negotiate message to the NOC ASA supplying TBD. If successfully received, the NOC ASA must reply with an End Negotiate message. From then on, any OAM communication between the NOC and the node in question will proceed over the ACP using the information TBD.

The format and semantics of Intent are not yet defined, although some aspects are discussed in . Here we assume that Intent is supplied to the whole network as a single file and that the file is obtained by each node that needs it via a specific Uniform Resource Identifier, typically a URL. We also assume that Intent, within a given autonomic domain, is qualified by a monotonically increasing version number, so that nodes can determine if their current copy of Intent is out of date. (A timestamp is not used for this purpose, since it would depend on all nodes having consistent clocks.) Thus, an Intent repository announces itself to all nodes by use of the "AN_intent_repo" objective. This is a synchronization objective primarily intended to be flooded using the GRASP Flood Synchronization (M_FLOOD) message. An example of the objective is informally:

The formal CDDL definition is:

A node that needs to obtain or update Intent will use the latest received version of this objective to check if the version number has increased, and will use the given URI to obtain the current Intent if necessary.

An ASA for IPv6 prefix management is described in . It requires two GRASP objectives. An example of the first objective is informally:

The formal CDDL definition is:

The second objective is intended for flooding out non-default parameters for prefix management:

Any ASA that floods one of the above objectives should do so at a carefully chosen frequency. Recipient nodes may be starting up, reconnecting, or waking up from sleep, so floods need to be refreshed periodically. On the other hand, excessive flooding will consume bandwidth, CPU and battery capacity throughout the network, and might even resemble a DoS attack. A general guideline is to flood an objective once immediately after its value is initialised or changed, and then repeat the flood at intervals of at least 30 seconds. Additionally, the flooding interval should be slightly jittered to avoid synchronicity with other floods. Finally, the value of a flooded objective should change as rarely as possible (on a timescale of at least minutes, not seconds).

General security issues for GRASP are covered in . Specific issues that are not mentioned above are discussed in the referenced drafts for each use case.

IANA is requested to add the following entries to the GRASP Objective Names Table registry created by :

Toerless Eckert, Max Pritikin, Michael Richardson

draft-carpenter-anima-ani-objectives-01, 2017-02-13: Added prefix management case Updated objectives for BRSKI Editorial corrections draft-carpenter-anima-ani-objectives-00, 2016-11-15: Initial version