Re: [secdir] Secdir review of draft-ietf-anima-reference-model-06

[Toerless Eckert <[e-mail]>]

Thanks for the review, Radia

Some perspective on the design choices made by ANIMA re to this group
security (and i'll reference this in the sec review of ACP spec that i am
now trying to get back to after an NMI i am trying to finish):

a) As Brian mentioned and as the ACP spec (draft-ietf-anima-autonomic-control-plane)
   in section 1.1 explains in more detail than the reference model, the prime
   target for ANI are professional managed networks, and IoT is only addressed
   opportunistically right now. Meaning: there are likely things missing for IoT,
   such as scale-down aspects. Other WGs are already working on those (like 6tisch).

b) The model of "group-security" of the ANI (either you're in, or you're out),
   is not the sufficient solves-all for security, but it is the necessary base
   level of security. For once to meet the original design goal of our current
   charter:

   The autonomic network architecture as passed from IRTF/NMRG in rfc7575 to ANIMA
   is meant to enable fully distributed peer-to-peer self-organization and operations
   of intelligent network devices/services without an assumption of any centralized
   backend that is orchestrating the network.

c) Consider just the security methods we have today in distributed protocols.
   Every protocol has its own variant of peer-to-peer security: every IGP, BGP,
   multicast protocols and so on. reinvention of the wheel over and over. And even
   though a lot of security exists for such protocols, it is not even widely
   deployed for most of them. So allowing the next round of distributed
   protocols/services to be build without having to reinvent that wheel was one
   key goal. [ Likewise also the CBOR(binary JSON) and common discovery mechanisms
   of GRASP are tools to avoid the reinvention of discovery and encoding for every
   new distributed protocol.]

   Note also that the fully automated PKI architecture of ANI allows to remove
   suspcious nodes from the domain (group trust). 

d) ANI also uses this group-security to create a cryptographic version of standard
   "clamshell" security in network operations - even without building new protocols
   as proposed in c)". This is what the use case of ANI for centralized management
   is all about (RFC8368). Classically this security is done through ACL, separating
   "inside management" addresses from "user addresses", so replacing that with
   the cryptographic secured ANI model is certainly a big step to more security.

e) Instead of just having a single "controller" empowered to have more control than
   other nodes as you suggest, i did suggest the notion of "roles" in the ACP
   spec A.10.5, also embodied via the ANI domain certificates.
   
   The reason for not including this into the normative part of the
   ACP spec (and therefore also not into the current reference model document)
   is that pretty much everyting in the ACP spec if very much based on existing
   commercial implementations (plus trying to fix in the standard docs details
   we learned to be not good in products and/or requested by WG discussion).  The
   role assignment is more novel, not tested in deployment, and therefore better
   separated out.  Also, it would be a part of the solution that fully peer-to-peer
   networks would likely not want.

   Finally, just specifying the security model as in A.10.5 is not the hard part of
   role based security. Sitting down and defining the policies implied for the
   important existing OAM services in nodes and the different type of roles (is NOC 
   vs. non-NOC node good enough) will take more work and should be done with more time.
   At this stage of the ANI docs, it would just be scope creep for the existing docs.

f) The real fun part would actually be how a full peer-to-peer autonomic network
   with maybe just the existing group-security or even no security at all initially
   would try to bootstrap itself into a more structured security model. Alas,
   that is IMHO far beyond what IETF or especially an OPS WG like ANIMA could or
   should do. But i did bring this up tangentially in my IETF 102 DINRG talk
   about ANIMA. Distributed voting/decision making is in scope there, so distributed
   security and peer-to-peer role role would certainly be a good use-case area.

   Alas, while being more fun, i think like you that e) is what we should do next
   in ANIMA because it is more immediately necessary/deployable. If you would like
   to contribute to that follow-up spec, that would be great!

g) Final note: the reference model is really only focussing on the fully distributed
   ANI -> Autonomic Network primary target of ANIMA. My considerations above are
   also inclusive of the use of ANI standalone, e.g.: for centralized NOC operations,
   so please do not expect that everything i said is or should be in the reference
   model doc. For example re. suggestions like "sub-domains vs. what i wrote in
   f), i think the evolution of the fully distributed autonomic network is a lot
   more complex..

Cheers & thanks for the review

    Toerless

On Tue, Aug 21, 2018 at 09:29:34PM -0700, Radia Perlman wrote:
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.
> 
> These comments were written primarily for the benefit of the security area
> directors. Document editors and WG chairs should treat these comments just
> like any other last call comments.
> 
> 
> 
> This document is an overview document (intended as informational)
> introducing a large collection of I-Ds (intended as Proposed) describing
> autonomic networking. Aimed at the Internet of Things with devices with
> very little in the way of user interface other than over the network, the
> design goal is to be maximally auto-configuring. Security is bootstrapped
> using private keys and certificates installed by the manufacturer, where to
> first goal is to join new devices to some sort of domain.
> 
> 
> 
> The most suspicious thing from a security standpoint is that it appears all
> of the devices in a domain implicitly trust one another. This means that
> bringing in the proverbial light bulb into your house could compromise your
> whole house if the light bulb had a Trojan horse installed or some sort of
> bug that allowed it to be compromised. There is some mention of addressing
> this issue in the future, but unless I???m misunderstanding the approach this
> seems like a very dangerous thing to deploy even initially. It makes much
> more sense for each installed device to first become manageable by a single
> other device in the domain. That first management device could cautiously
> expand trust further.
> 
> 
> 
> The dangers are well summarized in Section 9 (Security Considerations).
> Section 9.2 includes this text:
> 
> 
> 
> The above threats are in principle comparable to other solutions: In
> 
> the presence of design, implementation or operational errors,
> 
> security is no longer guaranteed. However, the distributed nature of
> 
> AN, specifically the Autonomic Control Plane, increases the threat
> 
> surface significantly. For example, a compromised device may have
> 
> full IP reachability to all other devices inside the ACP, and can use
> 
> all AN methods and protocols.
> 
> 
> 
> For the next phase of the ANIMA work it is therefore recommended to
> 
> introduce a sub-domain security model, to reduce the attack surface
> 
> and not expose a full domain to a potential intruder. Furthermore,
> 
> additional security mechanisms on the ASA level should be considered
> 
> for high-risk autonomic functions.

-- 
---
[e-mail]