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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Thu, 11 Jul 2019 06:38:48 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Alissa's discuss that the conclusion of section 10(.3) should be
to recommend a manual configuration mode. Also with respect 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.

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.

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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 13:01:51 -0400

{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 <[email-masked]> 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).

    > 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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 17 Jul 2019 11:21:10 +0200

Hi!

Please see below.

> On 16. Jul 2019, at 19:01, Michael Richardson <[email-masked]> wrote:
> 
> 

No problem. I guess the discusses are more important to figure out first anyway.

> From the operations divisions of some buyers (operators) and sellers (vendors).

I was mostly thinking about discussing this case in the text, rather than add a specific mechanism. E.g. you could say c) is an option that can be used right away and a more dedicated interface could be considered in future.

> has multiple other ACP devices on it.

I guess that doesn’t map to the IoT case that is also discussed in the doc. However, this is a usual safety measure we are building in all protocols (expect there is a good reason to do otherwise), e.g. also for routing protocols, because you never know for sure how future deployment scenarios will look like.

>   sources cause only negligible traffic across the ACP.

That would be good!

Thanks!
Mirja

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Jul 2019 13:04:38 -0400

Mirja Kuehlewind <[email-masked]> wrote:
    >> 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.
    >> 
    >> 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).

    > I was mostly thinking about discussing this case in the text, rather
    > than add a specific mechanism. E.g. you could say c) is an option that
    > can be used right away and a more dedicated interface could be
    > considered in future.

The auditlog can not be used in advance to see if ownership will be
transfered.  It's retrospective.   So it does not provide a way for the buyer
to check if ownership can/will be transfered.  We would still need (b) in
order to notify the MASA of the intent to sell.

If the IETF wants to get into APIs for sales integration, I would be there,
but my feeling is that this is layers above where we normally go. (My
colleague Joseph Potvin hopes to convince us otherwise with with a HotRFC
talk on sunday).

    >>> 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.

    > I guess that doesn’t map to the IoT case that is also discussed in the
    > doc. However, this is a usual safety measure we are building in all
    > protocols (expect there is a good reason to do otherwise), e.g. also
    > for routing protocols, because you never know for sure how future
    > deployment scenarios will look like.

I have added some text as you suggest, btw.
I am concerned about the "IoT case that is also discussed", as we are trying
hard to not say anything normative about IoT in *this* document, because one
size does not fit all.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 18 Jul 2019 17:00:17 +0200

Hi Michael,

Okay sounds good. See some minor comments below.

> On 17. Jul 2019, at 19:04, Michael Richardson <[email-masked]> wrote:
> 
> 

Okay understood. I guess you could still say in this document that should a mechanism would be useful but left for future work (somewhere)...

> hard to not say anything normative about IoT in *this* document, because one

Yes, but even though you never now how such protocols are used in the end. And either your make clear that usage is clearly restricted to certain scenario for a good reason or you try to cover as much as you can.

Mirja