Re: [Anima] [Gen-art] dealing with many the secdir and genart comments [on draft-ietf-anima-bootstrapping-keyinfra]

On 2018-12-03 12:53, Michael Richardson wrote:
> 
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>     >> The authors seriously believe that this will result in an attempt to
>     >> boil the ocean.  Yes, BRSKI is exciting for many and opens many doors,
>     >> but in the context of the *ANIMA* Charter, we strongly think that this
>     >> document should leave the oceans alone, and deal only with the ANIMA
>     >> ACP usage.
> 
>     > Yes, violent agreement. From all the interest outside ANIMA, the basic
>     > idea of BRSKI is a big hit and will be re-used in other contexts. I
>     > think a strong statement about the specific scope of *this* document
>     > belongs in the Abstract and Introduction, with a comment that variant
>     > usages of BRSKI in other scenarios will be documented separately.
> 
> Brian, these are my proposed changes to the abstract, intro,
> and adding a section on ACP Applicability.  I think that there is probably
> more to say there.

Perhaps, but I think these changes clarify the scope correctly.

Thanks
     Brian

> 
> This has become issue #116.
> 
> diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml
> index 78ce2a3..e705904 100644
> --- a/dtbootstrap-anima-keyinfra.xml
> +++ b/dtbootstrap-anima-keyinfra.xml
> @@ -82,19 +82,21 @@
>  
>      <abstract>
>        <t>
> -        This document specifies automated bootstrapping of a remote secure
> -        key infrastructure (BRSKI) using manufacturer installed X.509 certificate, in
> -        combination with a manufacturer's authorizing service, both online and offline.
> +        This document specifies automated bootstrapping of an Autonomic
> +        Control Plane.  To do this a remote secure
> +        key infrastructure (BRSKI) is created using manufacturer installed
> +        X.509 certificate, in combination with a manufacturer's authorizing
> +        service, both online and offline. 
>          Bootstrapping a new device can occur using a routable address and a
>          cloud service, or using only link-local connectivity, or on
>          limited/disconnected networks. Support for lower security models,
>          including devices with minimal identity, is described for legacy reasons
>  
> @@ -103,7 +105,22 @@
>        <t>
>          BRSKI provides a solution for secure zero-touch (automated) bootstrap of
>          virgin (untouched) devices that are called pledges in this
> -        document. These pledges need to discover (or be discovered by) an
> +        document.
> +      </t>
> +      
> +      <t>
> +        This document primarily provides for the needs of
> +        the ISP and Enterprise focused ANIMA 
> +        <xref target="I-D.ietf-anima-autonomic-control-plane">Autonomic 
> +        Control Plane (ACP)</xref>.  Other users of the BRSKI protocol
> +        will need to provide separate applicability statements that
> +        include privacy and security considerations appropriate to that
> +        deployment.  Section <xref target="acpapplicability" /> explains the details
> +        applicability for this the ACP usage.
> +      </t>
> +      
> +      <t>
> +        This document describes how pledges discover (or be discovered by) an
>          element of the network domain to which the pledge belongs to perform
>          the bootstrap.  This element (device) is called the
>          registrar.  Before any other operation, pledge and registrar need to
> 
> @@ -2755,6 +2772,64 @@ Reference: [This document]
>  	  </t>
>  	</section>
>      </section>
> +    <section anchor="acpapplicability" title="Applicability to the Autonomic
> +                                              Control Plane">
> +      <t>
> +        This document provides a solution to the requirements for secure
> +        bootstrap set out in <xref target="RFC8368">Using an Autonomic Control Plane for
> +        Stable Connectivity of Network Operations, Administration, and
> +        Maintenance </xref>, 
> +        <xref target="I-D.ietf-anima-reference-model" >A Reference Model for
> +        Autonomic Networking</xref> and specifically the 
> +        <xref target="I-D.ietf-anima-autonomic-control-plane">An Autonomic
> +        Control Plane (ACP)</xref>, section 3.2 (Secure Bootstrap), and
> +        section 6.1 (ACP Domain, Certificate and Network).
> +      </t>
> +      <t>
> +        The protocol described in this document has appeal in a number of
> +        other non-ANIMA use cases.  Such uses of the protocol will be
> +        deploying into other environments with different tradeoffs of
> +        privacy, security, reliability and autonomy from manufacturers.
> +        As such those use cases will need to provide their own applicability
> +        statements, and will need to address unique privacy and security
> +        considerations for the environments in which they are used.
> +      </t>
> +      <t>
> +        The autonomic control plane that this document provides bootstrap
> +        for is typically a medium to large Internet Service Provider
> +        organization, or an equivalent Enterprise that has signficant layer-3
> +        router connectivity.  (A network consistenting of primarily layer-2
> +        is not excluded, but the adjacencies that the ACP will create and
> +        maintain will not reflect the topology until all devices participate
> +        in the ACP).
> +      </t>
> +      <t>
> +        As specified in the ANIMA charter, this work "..focuses on
> +        professionally-managed networks."  Such a network has an operator
> +        and can do things like like install, configure and operate the
> +        Registrar function.  The operator makes purchasing decisions
> +        and is aware of what manufacturers it expects to see on it's
> +        network.
> +      </t>
> +      <t>
> +        Such an operator also is capable of performing the traditional
> +        (craft serial-console) based bootstrap of devices. The zero-touch
> +        mechanism presented in this and the ACP document represents a
> +        signficiant efficiency: in particular it reduces the need to
> +        put senior experts on airplanes to configure devices in person.
> +        There is a recognition as the technology evolves that not every
> +        situation may work out, and occasionally a human still still have to
> +        visit.
> +      </t>
> +      <t>
> +        The BRSKI protocol is going into environments where there have
> +        already been quite a number of vendor proprietary management
> +        systems.  Those are not expected to go away quickly, but rather to
> +        leverage the secure credentials that are provisioned by BRSKI.  The
> +        connectivity requirements of said management systems are provided
> +        by the ACP.
> +      </t>
> +    </section>
>      <section anchor="privacyconsiderations" title="Privacy Considerations">
>        <section title="MASA audit log">
>        <t>
> @@ -3292,6 +3367,7 @@ Reference: [This document]
>  
>        <?rfc include="reference.I-D.ietf-anima-autonomic-control-plane" ?>
>        <?rfc include="reference.RFC.8366" ?>
> +      <?rfc include="reference.RFC.8368" ?>
>        <?rfc include="reference.I-D.ietf-anima-grasp" ?>
>  
>        <reference anchor="IDevID"
> 
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 