[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                       B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                                    B. Liu
Expires: August 17, 2017                    Huawei Technologies Co., Ltd
                                                       February 13, 2017


  Technical Objective Formats for the Autonomic Network Infrastructure
                draft-carpenter-anima-ani-objectives-01

Abstract

   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.

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 August 17, 2017.

Copyright Notice

   Copyright (c) 2017 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




Carpenter & Liu          Expires August 17, 2017                [Page 1]


Internet-Draft            ANI GRASP Objectives             February 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Objectives for Secure Bootstrap . . . . . . . . . . . . . . .   3
     2.1.  Flooded Objective for Join Registrar  . . . . . . . . . .   4
     2.2.  Negotiation Alternative for Join Registrar  . . . . . . .   5
     2.3.  Flooded Objective for Join Assistant  . . . . . . . . . .   5
   3.  Objective for Autonomic Control Plane . . . . . . . . . . . .   6
     3.1.  Flooding Alternative  . . . . . . . . . . . . . . . . . .   6
     3.2.  Negotiation Alternative . . . . . . . . . . . . . . . . .   7
   4.  Objective for Stable Connectivity of Network OAM  . . . . . .   8
   5.  Objective for Intent Distribution . . . . . . . . . . . . . .   8
   6.  Objectives for Prefix Management  . . . . . . . . . . . . . .   9
   7.  Flood Frequency . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  Change log [RFC Editor: Please remove] . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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 support 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 other early use cases for
   ANIMA are also considered:

      Secure Bootstrap.




Carpenter & Liu          Expires August 17, 2017                [Page 2]


Internet-Draft            ANI GRASP Objectives             February 2017


      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)
   [I-D.greevenbosch-appsawg-cbor-cddl].  Undefined CDDL terms are
   defined in [I-D.ietf-anima-grasp].

2.  Objectives for Secure Bootstrap

   Three ANI components are involved in the Bootstrapping Remote Secure
   Key Infrastructures (BRSKI) process described in
   [I-D.ietf-anima-bootstrapping-keyinfra]: 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 [I-D.ietf-anima-bootstrapping-keyinfra] and
   [I-D.ietf-anima-grasp].







Carpenter & Liu          Expires August 17, 2017                [Page 3]


Internet-Draft            ANI GRASP Objectives             February 2017


2.1.  Flooded Objective for Join Registrar

   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

     registrar-objective = ["AN_join_registrar", F_SYNCH, loop-count,
                           [max-hops, [*method]]]

     max-hops = uint ; loop-count at the source node

     method = text ; name of the BRSKI method supported

   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.








Carpenter & Liu          Expires August 17, 2017                [Page 4]


Internet-Draft            ANI GRASP Objectives             February 2017


2.2.  Negotiation Alternative for Join Registrar

   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:

  registrar-objective = ["AN_join_registrar", 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.

2.3.  Flooded Objective for Join Assistant

   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:



Carpenter & Liu          Expires August 17, 2017                [Page 5]


Internet-Draft            ANI GRASP Objectives             February 2017


     assistant-objective = ["AN_join_assistant", 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 Join Assistant that supports more than one
   method will flood multiple versions of the "AN_join_assistant"
   objective.

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 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.

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
   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:

     acp-objective = ["AN_ACP", F_SYNCH, 1, [*method]]

     method = text ; name of the connection method supported




Carpenter & Liu          Expires August 17, 2017                [Page 6]


Internet-Draft            ANI GRASP Objectives             February 2017


   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.

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","dTLS"]]

   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.

   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).







Carpenter & Liu          Expires August 17, 2017                [Page 7]


Internet-Draft            ANI GRASP Objectives             February 2017


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 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:

     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 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.

5.  Objective 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, 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:




Carpenter & Liu          Expires August 17, 2017                [Page 8]


Internet-Draft            ANI GRASP Objectives             February 2017


     ["AN_intent_repo", F_SYNCH, 6,
        [12345, "https://noc.example.com/Intent/"]]

   The formal CDDL definition is:

     intent-objective = ["AN_intent_repo", 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.  Objectives for Prefix Management

   An ASA for IPv6 prefix management is described in
   [I-D.ietf-anima-prefix-management].  It requires two GRASP objectives.
   An example of the first objective is informally:

     ["PrefixManager", F_NEG, 6,
       [True, 56, 0x20010db8f000ba000000000000000000]]

   The formal CDDL definition is:

     objective = ["PrefixManager", F_NEG, loop-count,
                    [PD-support, length, ?prefix]]

     PD-support = true / false   ; indicates whether sender supports PD
     length = 0..128             ; requested or offered prefix length
     prefix = bytes .size 16     ; prefix in binary format

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

     objective = ["PrefixManager.Params", objective-flags, text]

     loop-count = 0..255         ; as in the GRASP specification
     objective-flags /=          ; as in the GRASP specification

     ;The text object would be the relevant parameter definitions
     ;transmitted as a single string with all whitespace and
     ;format characters removed.






Carpenter & Liu          Expires August 17, 2017                [Page 9]


Internet-Draft            ANI GRASP Objectives             February 2017


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 each use case.

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_join_registrar
         AN_join_assistant
         AN_ACP
         AN_NOC
         AN_intent_repo
         PrefixManager
         PrefixManager.Params

10.  Acknowledgements

   Toerless Eckert, Max Pritikin, Michael Richardson

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.




Carpenter & Liu          Expires August 17, 2017               [Page 10]


Internet-Draft            ANI GRASP Objectives             February 2017


   [I-D.ietf-anima-grasp]
              Bormann, C., Carpenter, B., and B. Liu, "A Generic
              Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
              grasp-09 (work in progress), December 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-05 (work in progress), January 2017.

   [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.

   [I-D.ietf-anima-prefix-management]
              Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic
              IPv6 Edge Prefix Management in Large-scale Networks",
              draft-ietf-anima-prefix-management-02 (work in progress),
              January 2017.

   [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-02 (work in progress), February
              2017.

Appendix A.  Change log [RFC Editor: Please remove]

   draft-carpenter-anima-ani-objectives-01, 2017-02-13:

   Added prefix management case

   Updated objectives for BRSKI



Carpenter & Liu          Expires August 17, 2017               [Page 11]


Internet-Draft            ANI GRASP Objectives             February 2017


   Editorial corrections

   draft-carpenter-anima-ani-objectives-00, 2016-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
   Q22, Huawei Campus
   No.156 Beiqing Road
   Hai-Dian District, Beijing  100095
   P.R. China

   Email: leo.liubing@huawei.com

























Carpenter & Liu          Expires August 17, 2017               [Page 12]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/