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

[Michael Richardson <[e-mail]>]

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

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

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