Max, Cherry-picking your comments; I will respond to Toerless's detailed comments later:
On 18/11/2016 12:33, Max Pritikin (pritikin) wrote: > Some comments on the BRSKI discussion inline, > >> On Nov 17, 2016, at 3:17 PM, Toerless Eckert <[email protected]> wrote: >> >> >> Thanks Brian & Bing >> >> Inline >> > > The following quote levels appear to be direct or paraphrases from the > objectives draft. > I’m tempted not even to respond to this email thread due to the sloppy > quoting but we’ll see how it goes. > >>> This document defines several technical objectives for use with for >> ^^^^^^^^^^^^^^^^^^^^ >>> the Generic Autonomic Signaling Protocol (GRASP) >>> [I-D.ietf-anima-grasp]. > > [snip] I’m focusing on just bootstrap discussions > >>> Secure Bootstrap. >> >> ANI use case: bootstrapping autonomic devices, non-ANI use case: >> bootstrapping >> non-autonomic devices. > > Since its objectives for autonomic I don’t see that discussing non-autonomic > is necessary in this document. > The broader point that BRSKI need not be forced to be ANI specific is > important to re-enfoce, so thank you. Indeed. The context is when the pledge is GRASP-capable; for other pledges, mDNS applies. >> >>> 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. > > Pledge, Proxy, Registrar, MASA OK. Michael Richardson pointed out that other efforts use the other terms. > >> >> 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. > > This framing is probably better. We also must note that the Pledge > requirement to work when the proxy is remote also means those Pledges must > support the DNS mechanisms. Adding GRASP is truly an addition to the methods > not a replacement or an optimization. Sure. > >>> 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’. > > I’m not seeing a discussion of distance as a selection method within GRASP. > Is the ability to provide distance metrics a goal of GRASP? Is it specific to > bootstrapping? There is no discussion of logic using this form of metric in > the BRSKI document. OK, well, a while back Toerless sort of asked for this. He also asked for priority and weight (like mDNS offers) which I could add in the same way. If BRSKI is happy with just picking an arbitary registrar if there are several, we can drop it. > >> *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, > > This would be covered by the GRASP s3.5.4.3 ‘lifetime’ discussion? I don’t > see it as specific to bootstrapping. Yes. Both discovery and flood support a TTL, and I assume MDNS does too. So when any ASA goes away, its objectives will vanish at most TTL later. It's easy to write robust code that survives that. Demo at https://www.cs.auckland.ac.nz/~brian/graspy/brski/ ;-) >> 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 don’t see any discussion of deletion in the main GRASP document. How does > that work? Caches time out. Do we need to say more? Probably this belongs in draft-carpenter-anima-asa-guidelines Brian > - max > >> >> 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: [email protected] >>> >>> >>> Bing Liu >>> Huawei Technologies Co., Ltd >>> Q14, Huawei Campus >>> No.156 Beiqing Road >>> Hai-Dian District, Beijing 100095 >>> P.R. China >>> >>> Email: [email protected] >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Carpenter & Liu Expires May 22, 2017 [Page 10] >> >> _______________________________________________ >> Anima mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
