Re: Summarizing Meeting on BMC Aggregation

[Michael Richardson <mcr@sandelman.ca>]

[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]


Thank for the interesting call yesterday.
I don't think I will have the time to attend regularly, but we'll see.
I have code to write, ya know :-)

Richard Hanley <rhanley@google.com> wrote:
    > The definition of a machine here is relatively opaque, but it can be
    > thought of as an atomic physical unit for management. A machine is
    > then split into multiple domains, each of which is managed by some
    > management controller (most cases it would be a BMC). There may be
    > some cases where a domain has multiple BMCs for redundancy.

    > Domains are relatively close to each other physically. Sometimes they
    > will be in the same chassis/enclosure, while other cases they will be
    > in an adjacent tray.

    > One key point that was discussed in this meeting was that the data and
    > transport of these domains is relatively unconstrained. Domains may be
    > connected to the aggregator via a LAN, but there is a community need
    > to support other transports like SMBus and PCIe.

If I were designing this, I would define standard way to transport IPv6 over
SMBus and PCIe, and then use IPv6 Link-Local addresses, and call it all a
LAN.  This has three effects in my opinion:
1) all transports need and get security resulting in fewer bugs
2) no need to re-invent TCP or HTTPS
3) directly connected hosts have less inherent privilege.

The IETF ANIMA working group
    https://datatracker.ietf.org/wg/anima/documents/
has created an O&M mechanism called the Autonomic Control Plane.
It has a discovery and negotiation protocol (GRASP), and as well as
onboarding (BRSKI).  It is designed for exactly this kind of use.
https://datatracker.ietf.org/doc/rfc8368/  describes some of the high-level
design goals.  The documents are stuck in the RFC-EDITOR queue due to
cross-references, but will get RFC-numbers very soon.
I am one of the authors of BRSKI.

In addition, the IETF Remote Attestation WG (RATS), at:
   https://datatracker.ietf.org/wg/rats/documents/

has been working on an architectural document.   (We have people from TCG,
FIDO, Android, Global Platform, ...)   Actually, we have a few such
documents, and we are merging them, the live process visible at:
   https://github.com/ietf-rats-wg/architecture

In particular, I point you to this pull request which was discussed this past
Tuesday:
  https://github.com/ietf-rats-wg/architecture/pull/13/files#diff-daea007baaef3c42f94e996f540dcd76

Doesn't the composite device use case look very much like the aggregator
situation you are trying to create?  If you care about attestation (and I
think you said you did), then it seems like there are significant synergies
here.

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



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]