Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-00.txt

[Toerless Eckert <[e-mail]>]

Thanks Brian & Bing

Inline

>    This document defines several technical objectives for use with for
                                   ^^^^^^^^^^^^^^^^^^^^
>    the Generic Autonomic Signaling Protocol (GRASP)
>    [I-D.ietf-anima-grasp].

Given how GRASP defines the term "objective" very specific, it would be
good to either say "GRASP objectives" if that's what you meant to say,
or rephrase to avoid the word and resulting confusion.

GRASP is used by several autonomic service functions for signaling
between the ASA realising those functions - as outlined in...

Or just some good upfront statment how exactly you're using the ord
"objective" in this document and what different adjectives to it mean.

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

early autonomic use cases beyond the ANI are considered...

Not sure if you want to summarize a bit the use cases beyond naming them,
if you want, here's what i'd say:

>       Secure Bootstrap.

ANI use case: bootstrapping autonomic devices, non-ANI use case: bootstrapping
non-autonomic devices.

>       Autonomic Control Plane (ACP).

Part of the ANI, serving autonomic and non-autonomic use cases.

>       Stable Connectivity of Network OAM.

Primarily non-autonomic as it discusses SDN management via the ACP without
intent being involved (yet).

>       Intent Distribution.

ANI use case.

...
> 2.  Objectives for Secure Bootstrap
> 
>    Three components are involved in the Bootstrapping Remote Secure Key
          ^^ insert ANI
>    Infrastructures (BRSKI) process described in
>    [I-D.ietf-anima-bootstrapping-keyinfra]: the Registrar, the Join
>    Assistant (or Proxy), and the Joining Node (or Pledge). 

Pls. get the final official word for proxy/pledge. we're carrying around
too many terms and repeating them everywhere.

Note: ... Bootstrapping has more functions, such as MASA and CA, but we
do not foresee the need for GRASP signalling with them at this time.

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

I think this is not the right security claim to make. We do have important
use-cases where the proxy MUST be remote, eg: when i attach a
 pledge to just an open internet connection without any prior ANI
in the vicinity. And the security comparison of this setup vs. the one with
L2 is kinda complex and should maybe not had in this doc. 

I'd suggest:

Operationally, the most simple case is when proxy and pledge have a
link-local connection between each other. In this case, mutual discovery and
bootstrap can happen without any prior provisioning of helper information
such as DHCP parameters or DNS entries through which the pledge would have
to find the proxy otherwise. Instead, link-local multicast with GRASP can and
 will be used.

>    There may be multiple hops between the proxy and
>    the registrar.

Between registrar and proxy, there can and likely will be multiple hops,
but in an autonomic network, these hops will have autoconfigured ACP and
GRASP forwarders between them, so this connectivity too is zero-touch like
the link-local connectivity beteeen pledge and proxy.

>    Therefore, two different GRASP objectives are
>    required: one that is used over an existing secure network between
                                     the                      (ACP)
>    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].

And i need to check ACP draft ifhow i capture that fact there as well.
Especially that each ACP node needs to run a GRASP forwarder for that
hop-by-hop forwarding of the GRASP flood - securely.

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

Suggest to move that paragraph up before the proxy/registrar text to
make reading easier.

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

*rotfl* when i read the word radius i asked myself why we would do anything
with the radius protocol here. Diameter is also overloaded. 
"sender-loop-count" would be most descriptive.

Also, i would suggest to remove the informal representation and rather put
the information into the comments of the formal description:


     sender-loop-count = uint ; loop-count at the source node
                              ; 255 is a good default. May use smaller values
                              ; if diameter of ACP network is known
     method = text            ; Name of BRSKI metho supported
                              ; eg: "BRSKI-TLS"
                              ; Should have some pointer to where values are defined.

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

Just curious: If it would be possible to encode multiple methods in a
single objective, why would you prefer to use different ones ?

My preference for different objectives would be as follows, and maybe that's
good text to have:

A different objective is used for each method to most easy support
the option that independent ASAs are providing the registrar function for
different methods. For example, BRSKI-COAP would most likely be focussed
to help enrol also non-autonomic pledges and could have a range of
aspects that would make implementation in a separate ASA beneficial
(eg: different scale/policies for non-autonomic pledges).

Another point to mention is the timing of this, eg:

Active Registrars will send this objective flood announcement periodically
(whats a good periodicity ?). Proxies will discovery these messages.
A proxy can be active whenever it knows one or more registrars.

And then what happens when a registrar fails:
  - Can we describe the timeout behavior, eg: when/how will proxy learn
    that the registrar went away. Does a registrar ASA that is going down
    in a controlled fashion have a way to explicitly withdraw the objective ?

I know, this text/these questions would go beyoond just defining the
objective encoding, but i think it would help a lot to have this type
of concise summary of the GRASP objective behavior.

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

Unless we want to add this TTL forwarding detection scheme whose name i forgot.
(set TTL to 255, ignore on receiver messages with lower TTL).

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

That paragraph does not sound like the best sales pitch.  And again, i am
not sure if the negative security assessment you make is correct.

First of all, maybe move to an appendix given how this goes beyond 
our MTI (Mandatory To Implement).

Secondly: flooding announcements from proxies to pledges is based on
security assumptions that the network info (with proxies on the edge) is
well secured/protected, and that pledges are more vulnerable. Attackers
wold have to become active with flood multicasts to find a pledge which would
otherwise be quiet. And those attacker flood multicasts can be detected.

Eg: when we'd turn it around like you describe here, attackers could just
unicast answer to pledges and therefore attack the pledge with less
of a visible trail (aka: a valid proxy would not necessarily see the unicast
traffic between attacker and pledge).

But lets turn the assumptions around: In IoT, one might be foremost
concerned about the security of the infra (with the proxies). Let those
pledges multicast for bootstrap help, but our proxy may GRASP respond only
when it feels that's safe. For example, if the link between pledge and proxy
is some IoT radio with some vendor encryption/security (like in a lot of
low-power radio options), this argument might fly and make this order
of signaling preferrable.

>    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
> 
>    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
             ^^^^^^^ s/intervention/help/ ?
>    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
                                             ^^^^^^^^^^^ always when the ACP is capable and willing to connect to neighbbors
>    discover or detect new ACP neighbors or to remove failed neighbors.
> 
> 3.1.  Flooding Alternative

Indicating a "method" for the protocol is an undesirable attack vector.
Thats probably true for the BRSKI announcements as well, but i'll let
Max etc. argue that point.

In ACP, the ACP draft describes how the insecure GRASP signaling would
only indicate AN_ACP without parameters, and then any negotiation would
have to be subject to the node either just trying the methods it supports,
or building a TLS connection and running GRASP inside for negotiation.

I do like the flood and thats what i described in ACP draft. 

I would even like to see mthod being included in it,
but purely for operator diagnostics. Eg: the receiving ASA MUST NOT
change its behavior based on it.

Eg: Have a Diag element which might be structured, and which as it's
first element has the "methods" supported. 

I hope the diagnostics benefits outweigh the minor securitydownside it has.

> 3.2.  Negotiation Alternative

It seems as if you have no section for the TLS secured negotiation for the
ACP channel.  Why do you not simply reword this 3.2 to be exactly that ? 

Another question: For all those string names like for the "method",
do we need registries in the IETF ? 

> 4.  Objective for Stable Connectivity of Network OAM

Nice. Let me discuss high level some steps:

1. The way i imagine it, the NOC is a bunch of services, and not specifically
   a single "NOC" service. So for example, each ACP node should perform
   syslog to a NOC syslog service. Or authenticate data-plane
   sessions into the ACP node (netconf, SNMP, SSH,...) via a NOC
   authentication service (radius/diameter,...)

   A bunch of these services have already defined DNS-SD service names
   and sometimes also service-parameters. So a simple extensible approach
   would be to come up with a scheme how to map DNS-SD service announcement
   attributes into GRASP objectives that the NOC equipment would then flood
   (flooding like you described for the registrar seems like the easiest
    scalable way when the objective is required by the mayority of ACP nodes).
   
   This way we would not have to reinvent the whole namespace of services
   a NOC could have, and even if we have to invent new names, it wouldn't be
   in a silo, but we'd pick names that are free in DNS-SD, allocate them to
   DNS-SD registry, and e voila: no need to maintain additional registries for it.

2. You are correct that the NOC should know about wanting to know about
   devices in the network. Alas, there are a bunch of things we could do,
   and i am not sure how we could most easily make progress.

   Here's roughly how i think it could look:

   NOC ACP-topology ASA is the entity wanting to track network topology.
   It would also indicate to some backend whenever new devices show up.
   The parameters to it's objective could indicate a lot of options:

   - announce yourself
     - always after you've connected
     - only when you're in "unconfigured state"
   - announce ACP neighbors
     - when they connet
     - when they disconnect
   
   I am not sure if the actual announcements then to this service should be
   done via GRASP (as a negotiation ? ) or some other protocol. Syslog comes
   to mind, but it has reliability problems.

> 5.  Objectives for Intent Distribution

Except for the ACP channel protocol negotiation, all of the above
is about the simple GRASP flood. Which makes me happy (because it's simple),
and you probably unhappy (because it doesn't explore all the options of GRASP).

So i wonder: Isn't Intent something where we would need a more intelligent
use of GRASP than just good ol' flood ?

Aka: If we had an Intent agent on every ACP node that has GRASP
negotiation with each neighbor: I could modify intent on any node,
and that node would negotiate with it's neighbors that it had a new version,
and this is what would make that new intent flow hop-by-hop across the
autonomic network via Intent ASAs.

And there are tricky parts here: If the network becomes partitioned and
intent gets modified on both sides and then there is a network merge again -
how do you resolve the conflict. Whatever method of signaling you use.

If we want to solve the problem with absolute timestamps, it seems to me
as if i'd still need relative timestamps:

  Network i connected whole network have version I1 with originator
  assigned timestamp I1t.

  Network partitions into part A and part B.
  Node in part A modifies intent to I1+1 at time I1t+ta.
  Node in part B modifies intent to I1+1 at time I1t+tb.
   
  When network merges, the policy could be that all nodes would apply
  the intent that is newer. eg: lets assume intent in A was applied later.
  Nodes in B should be ablle to figure this out by using the relative
  time tracked against the last applied intent (I1/I1t).

Cheers
    Toerless

> 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: [e-mail]
> 
> 
>    Bing Liu
>    Huawei Technologies Co., Ltd
>    Q14, Huawei Campus
>    No.156 Beiqing Road
>    Hai-Dian District, Beijing  100095
>    P.R. China
> 
>    Email: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Carpenter & Liu           Expires May 22, 2017                 [Page 10]