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

[Brian E Carpenter <[e-mail]>]

This is a reply to an old but very interesting message. We're
working on an update to the draft. Some of Toerless's points
will be directly addressed in the new draft. Some of them are
out of scope since the draft only aims to define formats.
I have commented on a few others below.

On 18/11/2016 11:17, Toerless Eckert wrote:
> 
> 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.

I'm reluctant to do that. Unfortunately CDDL is still a long way from
the standards track, so although we definitely need to use it, we
may need to adapt this document (and the GRASP spec) to avoid a formal
normative reference. So I want to minimise the amount of CDDL text.

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

Agreed, but the advantage of retaining the [*method] syntax is that
it gives the implementer free choice: one or multiple methods per
objective.

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

Not sure. Doesn't that really belong with BRSKI itself?

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

Nevertheless, I am told that BRSKI wants Flood for this so we'll drop
the negotiation option. Conversely, BRSKI seems less sure what it wants
for the proxy-discovers-registrar case.

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

Why? If the attacker doesn't have the domain cert, they can do nothing.
If they do have the domain cert, they can do anything.

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

Yes. On balance I think Flood is the cleanest solution for
infrastructure elements. Everybody needs them and the method
is robust since it can simply be repeated at some reasonable rate.

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

? You seem to be conflating GRASP negotiation with TLS negotiation?

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

I don't know. I'm a bit reluctant to say yes, because then every
ASA designer will want their own registry.

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

Well, see draft-liu-anima-grasp-distribution.

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

You could but whether that would be a good thing is another
discussion. For the moment we're talking about an Intent repository.
Using a version number rather than a timestamp avoids quite
a few problems. But since it's a repository model I think we
should rename the objective as "AN_intent-repo".

   Brian

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