Technical Objective Formats for the Autonomic Network InfrastructureDepartment of Computer ScienceUniversity of AucklandPB 92019Auckland1142New Zealandbrian.e.carpenter@gmail.comHuawei Technologies Co., LtdQ22, Huawei CampusNo.156 Beiqing RoadHai-Dian District, Beijing100095P.R. Chinaleo.liubing@huawei.comThis 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 ManagementThe 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 Richardsondraft-carpenter-anima-ani-objectives-01, 2017-02-13:
Added prefix management case
Updated objectives for BRSKI
Editorial correctionsdraft-carpenter-anima-ani-objectives-00, 2016-11-15:
Initial version