Network Working Group B. Carpenter
Internet-Draft Univ. of Auckland
Intended status: Informational B. Liu
Expires: May 22, 2017 Huawei Technologies Co., Ltd
November 18, 2016
Technical Objectives for the Autonomic Network Infrastructure
draft-carpenter-anima-ani-objectives-00
Abstract
This document defines several technical objectives for the Generic
Autonomic Signaling Protocol (GRASP) for use by components of the
Autonomic Networking Infrastructure outlined in the ANIMA reference
model.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 22, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Carpenter & Liu Expires May 22, 2017 [Page 1]
Internet-Draft ANI GRASP Objectives November 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Objectives for Secure Bootstrap . . . . . . . . . . . . . . . 3
2.1. Flooding Alternative for Proxy . . . . . . . . . . . . . 4
2.2. Negotiation Alternative for Proxy . . . . . . . . . . . . 4
3. Objective for Autonomic Control Plane . . . . . . . . . . . . 5
3.1. Flooding Alternative . . . . . . . . . . . . . . . . . . 5
3.2. Negotiation Alternative . . . . . . . . . . . . . . . . . 6
4. Objective for Stable Connectivity of Network OAM . . . . . . 7
5. Objectives for Intent Distribution . . . . . . . . . . . . . 7
6. Objective for Prefix Management . . . . . . . . . . . . . . . 8
7. Flood Frequency . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document defines several technical objectives for use with for
the Generic Autonomic Signaling Protocol (GRASP)
[I-D.ietf-anima-grasp]. They are intended for use by corresponding
Autonomic Service Agents (ASAs) that realise infrastructure
components of the Autonomic Network Infrastructure (ANI) outlined in
the ANIMA reference model [I-D.ietf-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 early use cases for ANIMA are
also considered:
Secure Bootstrap.
Autonomic Control Plane (ACP).
Stable Connectivity of Network OAM.
Carpenter & Liu Expires May 22, 2017 [Page 2]
Internet-Draft ANI GRASP Objectives November 2016
Intent Distribution.
Prefix Management
The following sections define GRASP objectives for each of these
cases. They are described an informal object notation and formally
using CBOR data definition language (CDDL)
[I-D.greevenbosch-appsawg-cbor-cddl]. Undefined CDDL terms are
defined in [I-D.ietf-anima-grasp].
2. Objectives for Secure Bootstrap
Three components are involved in the Bootstrapping Remote Secure Key
Infrastructures (BRSKI) process described in
[I-D.ietf-anima-bootstrapping-keyinfra]: the Registrar, the Join
Assistant (or Proxy), and the Joining Node (or Pledge). The proxy
and the pledge are attached to the same link-layer and use link-local
communications only, to minimize exposure to eavesdroppers and
malicious nodes. There may be multiple hops between the proxy and
the registrar. Therefore, two different GRASP objectives are
required: one that is used over an existing secure network 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 [I-D.ietf-anima-bootstrapping-keyinfra] and
[I-D.ietf-anima-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.
A registrar announces itself to potential proxies by use of the
"AN_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_registrar", F_SYNCH, loop_count, [7, "BRSKI-TLS"]]
The formal CDDL definition is
registrar-objective = ["AN_registrar", F_SYNCH, loop-count, [radius,
method]]
Carpenter & Liu Expires May 22, 2017 [Page 3]
Internet-Draft ANI GRASP Objectives November 2016
radius = uint ; loop-count at the source node
method = text ; name of the BRSKI method supported
The 'radius' parameter allows a proxy that receives this message to
determine its distance in hops from the registrar, by subtracting the
received 'loop-count' from 'radius'.
The 'method' parameter indicates the specific BRSKI method available
at the given locator. The initial possible values are "BRSKI-TLS"
and "BRSKI-COAP". A registrar that supports more than one method
will flood multiple versions of the "AN_registrar" objective.
2.1. Flooding Alternative for Proxy
A proxy announces itself to potential pledges by use of the
"AN_proxy" 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_proxy", F_SYNCH, 1, "BRSKI-TLS"]
The formal CDDL definition is
proxy-objective = ["AN_proxy", F_SYNCH, 1, method]
method = text ; name of the BRSKI method supported
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 proxy that supports more than one method will
flood multiple versions of the "AN_proxy" objective.
2.2. Negotiation Alternative for Proxy
This alternative to "AN_proxy" uses additional features of GRASP. It
requires additional complexity in the pledge, and requires the pledge
to announce its existence to any on-link eavesdroppers via a
Discovery message. It is therefore not recommended on security
grounds, but is defined here for completeness.
A pledge discovers a local proxy and negotiates a BRSKI method with
it by use of the "AN_join" objective. First, the pledge performs
GRASP discovery, with the loop-count set to 1 and limited to link-
local addresses. If multiple responses occur, it chooses one by an
Carpenter & Liu Expires May 22, 2017 [Page 4]
Internet-Draft ANI GRASP Objectives November 2016
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", F_NEG, 6, ["BRSKI-COAP","BRSKI-TLS"]]
The formal CDDL definition is
join-objective = ["AN_join", F_NEG, loop-count, [*method]]
method = text ; name of the BRSKI method supported
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.
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).
3. Objective for Autonomic Control Plane
The Autonomic Control Plane (ACP)
[I-D.ietf-anima-autonomic-control-plane] 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 runs permanently, in order to
discover or detect new ACP neighbors or to remove failed neighbors.
3.1. Flooding Alternative
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
Carpenter & Liu Expires May 22, 2017 [Page 5]
Internet-Draft ANI GRASP Objectives November 2016
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"]
The formal CDDL definition is
acp-objective = ["AN_ACP", F_SYNCH, 1, method]
method = text ; name of the connection method supported
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" and "TLS". A node that supports more than one method will
flood multiple versions of the "AN_ACP" objective.
Note that a node serving both as an ACP node and BRSKI proxy may
choose to distribute the "AN_ACP" objectives and "AN_proxy"
objectives in the same message, since GRASP allows multiple
objectives in one Flood message.
3.2. Negotiation Alternative
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","TLS"]]
The formal CDDL definition is
acp-objective = ["AN_ACP", F_NEG, loop-count, [*method]]
method = text ; name of the connection method supported
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.
Carpenter & Liu Expires May 22, 2017 [Page 6]
Internet-Draft ANI GRASP Objectives November 2016
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).
4. Objective for Stable Connectivity of Network OAM
For OAM purposes [I-D.ietf-anima-stable-connectivity], 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 is requires s
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
noc-objective = ["AN_NOC", F_NEG, loop-count, [TBD]]
TBD = any ; node information to be defined
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 rely 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.
5. Objectives for Intent Distribution
The format and semantics of Intent are not yet defined, although some
aspects are discussed in [I-D.du-anima-an-intent]. 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, a source of Intent announces itself to all nodes by use of the
"AN_intent" objective. This is a synchronization objective primarily
Carpenter & Liu Expires May 22, 2017 [Page 7]
Internet-Draft ANI GRASP Objectives November 2016
intended to be flooded using the GRASP Flood Synchronization
(M_FLOOD) message. An example of the objective is informally:
["AN_intent", F_SYNCH, loop_count, [12345, "https://noc.example.com/
Intent/"]
The formal CDDL definition is
intent-objective = ["AN_Intent", F_SYNCH, loop-count, [version-
number,uri]]
version-number = uint
uri = text ; URI conforming to RFC 3986
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.
6. Objective for Prefix Management
TBD
7. Flood Frequency
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).
8. Security Considerations
General security issues for GRASP are covered in
[I-D.ietf-anima-grasp]. Specific issues that are not mentioned above
are discussed in the referenced drafts for BRSKI, ACP, stable
connectivity and Intent.
Carpenter & Liu Expires May 22, 2017 [Page 8]
Internet-Draft ANI GRASP Objectives November 2016
9. IANA Considerations
IANA is requested to add the following entries to the GRASP Objective
Names Table registry created by [I-D.ietf-anima-grasp]:
AN_registrar
AN_proxy
AN_ACP
AN_NOC
AN_intent
10. Acknowledgements
TBD.
11. References
11.1. Normative References
[I-D.greevenbosch-appsawg-cbor-cddl]
Vigano, C. and H. Birkholz, "CBOR data definition language
(CDDL): a notational convention to express CBOR data
structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work
in progress), September 2016.
[I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-08 (work in progress), October 2016.
11.2. Informative References
[I-D.du-anima-an-intent]
Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M.
Behringer, "ANIMA Intent Policy and Format", draft-du-
anima-an-intent-04 (work in progress), July 2016.
[I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
Control Plane", draft-ietf-anima-autonomic-control-
plane-04 (work in progress), October 2016.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-04 (work in progress), October 2016.
Carpenter & Liu Expires May 22, 2017 [Page 9]
Internet-Draft ANI GRASP Objectives November 2016
[I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
Reference Model for Autonomic Networking", draft-ietf-
anima-reference-model-02 (work in progress), July 2016.
[I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-01 (work in progress), July
2016.
Appendix A. Change log [RFC Editor: Please remove]
draft-carpenter-anima-ani-objectives-00, 2018-11-15:
Initial version
Authors' Addresses
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Bing Liu
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing 100095
P.R. China
Email: leo.liubing@huawei.com
Carpenter & Liu Expires May 22, 2017 [Page 10]