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

[Mirja Kuehlewind <[e-mail]>]

Hi!

Please see below.

> On 16. Jul 2019, at 19:01, Michael Richardson <[e-mail]> wrote:
> 
> 
> {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}

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

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

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.

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

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.

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

That would be good!

Thanks!
Mirja


> 
> --
> ]               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 =-
> 
> 
>