From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de,
 anima-chairs@ietf.org, The IESG <iesg@ietf.org>, anima@ietf.org
In-Reply-To: <DB320B9E-2AB8-4EFB-A50B-F7207D59C068@kuehlewind.net>
References: <156285232840.32370.18027192977627346503.idtracker@ietfa.amsl.com>
 <24814.1563296511@localhost>
 <DB320B9E-2AB8-4EFB-A50B-F7207D59C068@kuehlewind.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 17 Jul 2019 13:04:38 -0400
Message-ID: <16131.1563383078@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/BPKEGpau03TPlzpofE2puEEAXoY>
Subject: Re: [Anima] 
 =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?=
 =?utf-8?q?-ietf-anima-bootstrapping-keyinfra-22=3A_=28with_COMMENT=29?=
Precedence: list

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
    >> okay.
    >>=20
    >>> 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.
    >>=20
    >> So you are asking for an additional API from the JRC to the MASA.  It
    >> would need to include something like:
    >>=20
    >> 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 cou=
ld
    >> 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.
    >>=20
    >> (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.
    >>=20
    >> I can imagine creating such APIs.  There probably needs to be some
    >> buyer-JRC/seller-JRC APIs, or at least conventions.  This could easi=
ly
    >> 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 buy=
er
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:
    >>=20
    >>> 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.
    >>=20
    >> I take your point.  In the ANIMA ACP situation, please think about t=
he
    >> 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=E2=80=99t map to the IoT case that is also discuss=
ed 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.

=2D-=20
]               Never tell me the odds!                 | ipv6 mesh network=
s [
]   Michael Richardson, Sandelman Software Works        |    IoT architect =
  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails  =
  [



--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0vVSUACgkQgItw+93Q
3WWi/QgAt8aFdjz3t4Od+b7rFCQSl07Tj//LF0aKoFvaFoIsevW0aVepOuzIKklf
Iq6/9Ej0uiwACdmcfiScZk+zbZrtspFbtVamn4SmUYMDOPDNlMjcdvkVOs4G4/07
DnSyauJH7n/Fp8mx/QyLCk0ph5GqVrAWWhRKSdqAiWXcbBvmY5fEPtDrY0dC/kvC
ymFIL4Y0bjnWtUvKWA2gknzY5rHUCNctUJUdl2emB5GYGzejHVTJyH2uxWCD6bVs
1NeqMUnd0wfZqruJz8aev2CbCIq+QZK4zpmkxXEbmXUDPUfGaPS/6Pt3iHBYNh+f
5VxkCDfnLQkJnzwMwGbU5RT3uMR0YA==
=jaxL
-----END PGP SIGNATURE-----
--=-=-=--