[Anima] some comments on -- draft-ietf-anima-grasp-01

[Michael Richardson <[e-mail]>]

section 2.1, part 2.

>2.1.  Requirements for Discovery
>   2.  When an ASA first starts up, it has no knowledge of the specific
>   network to which it is attached.  Therefore the discovery process
>   must be able to support any network scenario, assuming only that the
>   device concerned is bootstrapped from factory condition.

I'm thinking that there is more to this: the ASA may assume that the device,
having been bootstrapped, now has a secured ACP with the local machine.

(The exception being a bootstrap ASA, but I'm not convinced GRASP should be
used for that)

I think that we should also need to think about channel binding mechanisms so
that the ASA doesn't have to do all it's own security work, and so that an
ASA can potentially put a bit more trust into the source address of a packet.

We also need to discuss how/if an ASA that do wants to do its own security
gets access to the validated device identity. The possibility that the device
would act as a sub-CA signing each of the ASAs.  Another model would have the
device enroll each of the ASA into an ASA-type-specific CA. (Finding/creating
that ASA-specific-CA being a meta goal.)

>   8.  The discovery process must not generate excessive (multicast)
>   traffic and must take account of sleeping nodes in the case of a
>   resource-constrained network [RFC7228].

First, 7228 defines constrained devices, and challenged networks.
"resource-constrained network" isn't a thing in 7228, so that needs to be
clarified.

Second, if the ACP is implemented as I think it ought to, we won't support
any kind of native multicast.  We could provide multicast via
draft-ietf/roll-trickle-mcast, or draft-bergmann-bier-ccast perhaps, or PIM.

I don't think it's worth doing any of these things at the IP layer, I think
that there will be grasp daemons running at each vertice of the ACP, and so I
think that we should do flooding at the application layer, much like DNCP
does for Homenet.

>   25.  The protocol needs to be fully secured against forged messages
>   and man-in-the middle attacks, and secured as much as reasonably
>   possible against denial of service attacks.  It needs to be capable
>   of encryption in order to resist unwanted monitoring, although this
>   capability may not be required in all deployments.  However, it is
>   not required that the protocol itself provides these security
>   features; it may depend on an existing secure environment.

I feel like there is too much hedging.  This is where my comment that we seem
to be writing at cross-purposes come to play.   I think it would be better to
say:

        + 25.  The protocol is expected to run on top of a secure
               infrastructure provided by the Autonomic Control Plane (ACP)
               [I-D.ietf-anima-autonomic-control-plane].  The ACP is
               expected to defend against: forged messages and man-in-the
               middle attacks, as well as provide for mitigation of against
               denial of service attacks from nodes not into the ACP.  The
               ACP is further expected to provide a private channel.

I think that the words here:
  > , although this
  >   capability may not be required in all deployments.

are insufficiently supported.  Why should the protocol be complicated in this
fashion?  3.3.1 goes on to say:

>3.3.1.  Required External Security Mechanism
>
>   The protocol SHOULD run within a secure Autonomic Control Plane (ACP)
>   [I-D.ietf-anima-autonomic-control-plane].  The ACP MUST provide a
>   status indicator to inform GRASP that the ACP is operational.
>
>   If there is no ACP, the protocol MUST use another form of strong
>   authentication and SHOULD use a form of strong encryption.  TLS
>   [RFC5246] or DTLS [RFC6347] are RECOMMENDED for this purpose, based
>   on a local Public Key Infrastructure (PKI) [RFC5280] managed within
>   the autonomic network itself.

so, let's not sit on the fence here.  Can we please decide if we want an ACP,
and if we don't, then let's stop working on it.

If the designers of GRASP are thinking of using it in some other
non-Autonomic situation, then please write a new document that inherits from
draft-ietf-anima-grasp for that purpose.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-