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

[Mirja Kuehlewind <[e-mail]>]

Hi Michael,

Okay sounds good. See some minor comments below.

> On 17. Jul 2019, at 19:04, Michael Richardson <[e-mail]> wrote:
> 
> 
> Mirja Kuehlewind <[e-mail]> 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.
>>> 
>>> 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.
> 
> 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).

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

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

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


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