Re: [Anima] Mirja Kühlewind's No Objection on draft-ietf-anima-bootstrapping-keyinfra-22: (with COMMENT)

[Michael Richardson <[e-mail]>]

{I almost hit the 'n'ext key on this email when I read you had No
Objection...  I wonder if the DT should link the comments in the DT
to the thread that results}

Mirja Kühlewind via Datatracker <[e-mail]> wrote:
    > I agree with Alissa's discuss that the conclusion of section 10(.3)
    > should be to recommend a manual configuration mode. Also with respect

okay.

    > to section 10.2: if ownership is "enforced" by the manufacturer, there
    > should also probably be a way for the buyer to check if ownership was
    > transferred by the saler during the re-sale process.

So you are asking for an additional API from the JRC to the MASA.
It would need to include something like:

a) a POST from selling-JRC to MASA to ask MASA for if a resale would be granted.
   This could result in some statement that the seller could show to the
   buyer that would validate that the transaction can occur.
b) a POST from selling-JRC to MASA to indicate to whom the sale was made,
   this would have to include some reference to the buyer.
c) a GET from the selling-JRc and also buyer-JRC that would ask who
   the current owners is supposed to be.

(c) could in theory be done with the auditlog, provided that the (b) process
installed the buyer as an authorized entity that could query the auditlog.
It would probably be better to have the MASA do the thinking here, rather
than the JRC.

I can imagine creating such APIs.  There probably needs to be some
buyer-JRC/seller-JRC APIs, or at least conventions.  This could easily become
a rathole attracting all sorts of online sales API.  Were this to be added to
this document, or to an extension document, I'd want to have significant
involvement from some people who build financial/sales systems, or at least
From the operations divisions of some buyers (operators) and sellers (vendors).

    > Two other small comments on more load related points:

    > 1) sec 4.1: "Connection attempts SHOULD be run in parallel to avoid
    > head of queue problems wherein an attacker running a fake proxy or
    > registrar could perform protocol actions intentionally slowly.  The
    > pledge SHOULD continue to listen to for additional GRASP M_FLOOD
    > messages during the connection attempts."  One minor comment: Maybe
    > also say explicitly, while running in parallel, one should not send all
    > initial messages at exactly the same time but pace them out (e.g. one
    > every 3 secs) to avoid network overload when initial connectivity is
    > very constraint.

I take your point.
In the ANIMA ACP situation, please think about the situation as being a
multiport BFR with three+ 100G fiber connections to other cities. Or, one or
more ports plugged into some (unmanaged or probably outsourced) L2 fabric that
has multiple other ACP devices on it.

    > 2) sec 4.3: " It must be sufficiently low that the aggregate amount of
    > periodic M_FLOODs from all EST servers causes negligible traffic across
    > the ACP."  I know this is a little bit a blurry requirement but I would
    > still like to see a MUST here. Or maybe give an upper bound for the
    > maximum frequency, e.g. MUST NOT send more than once per minute...? Not
    > sure it there is a reasonable value here.

I'm hesistant to write anything specific here.  There are two reasons.
One is that we really don't have any experience running ACPs yet, or how much
bandwidth will typically be available, and we also don't know how many JRCs
a typical operator might deploy.

The second reason is that I think that this should really be dealt with in:
  https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/
(or mabe  https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/)

ACP section 6.1.4.1 defines an M_FLOOD for the SRV.est. This is not
necessarily the JRC, btw, as certificate renewal might be performed by
a different system than enrollment.  It does say:

   The M_FLOOD message MUST be sent periodically.  The default SHOULD be
   60 seconds, the value SHOULD be operator configurable but SHOULD be
   not smaller than 60 seconds.  The frequency of sending MUST be such
   that the aggregate amount of periodic M_FLOODs from all flooding
   sources cause only negligible traffic across the ACP.

I will copy this text.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


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