Early Review of draft-nichols-iotops-defined-trust-transport-01
review-nichols-iotops-defined-trust-transport-01-iotdir-early-krishnan-2023-07-24-00

Reviewer: Toerless Eckert
Document: draft-nichols-iotops-defined-trust-transport-01

This is a partial review of the document.

I was officially asked to do IoTdir review but could not guarantee i would
have the time, so i did not respond and i was ultimately not assigned to do it.

I did find a bit of time to go through parts of the document today because i
was very interested in it.

I very much like the overall technology and think it is useful far beyond the
scoped goals of OT, such as an infrastructure for ASA in ANIMA. Likewise it may
have issues in some OT areas i can think ot - so it is overall a great
technology to experiment with.

I have actually no good experience with the requirements against an individual
submission RFC, just trying to likely submit the first work of my own to that
track. So it is not clear to me what reasonable expectations against the text
are. I did stumble across a lot of nits i'd suggest to be resolved in IETF
track documents, but not clear about the right level of expectation here.

Overall, this document is very dense, and if i may be cynical - a lot of
research papers are often so dense, primarily also because of page limits in
research publications, and i think it leads to little educational value of many
research papers.

To document the work done so far for DefT in this to-be-RFC to few experts who
will understand how these components of quite a complex system do work together
i think this text is on the right path. Also i think in a lot of the
discussions of future options (which i didn't review in detail).

If on the other hand, the content is meant to be put into RFC format to further
proliferate the ideas to a broader, less-expert audience of desired adopters,
then more examples/explanatoins could be helpfull.  In general, there is a bit
of the operational perspective missing. E.g.: description of an example DevOps
process of how to build out an application and deploy/secure it in the network
with DefT vs. without it (best case, not assuming worst case manual configured
ACLs ;-)).

Given how research papers have all type of more or less useful author-hazing
with all their formatting requirements  i would like to mention that i would
see benefit in ASCII pictures for the graphics.
 None of them seem to be too difficult to build, and its still the RFC
 reference format.
There are by now also nice tools to automatically create nicer graphics
automatically from ASCII-art which many newer RFCs already use.

Overall: Thanks a lot for this work, and hope we can see this in time as an RFC.
And if you're interested to present at ANIMA and maybe discuss there as well,
feel free to ask for a slot.

Cheers
    Toerless

I felt the text overall is in many parts more of a research paper, expecting
knowledge/references to a large number of research papers. Which could be fine.
I don't

2       Network Working Group                                         K. Nichols
3       Internet-Draft                                               Pollere LLC
4       Intended status: Informational                               V. Jacobson
5       Expires: 4 October 2023                                             UCLA
6                                                                        R. King
7                                                          Operant Networks Inc.
8                                                                   2 April 2023

10            Defined-Trust Transport (DeftT) Protocol for Limited Domains
11                  draft-nichols-iotops-defined-trust-transport-01

13      Abstract

15         This document describes a broadcast-friendly, many-to-many Defined-
16         trust Transport (DeftT) that makes it simple to express and enforce

Nit: Use of DefT term before defining it.

17         application and deployment specific integrity, authentication, access
18         control and behavior constraints directly in the protocol stack.
19         DeftT is part of a Defined-trust Communications framework with an
20         example codebase, not a protocol specification.  Combined with IPv6
21         multicast and modern hardware-based methods for securing keys and
22         code, it provides an easy to use foundation for secure and efficient
23         communications in Limited Domains (RFC8799), in particular for
24         Operational Technology (OT) networks.

26      Status of This Memo

28         This Internet-Draft is submitted in full conformance with the
29         provisions of BCP 78 and BCP 79.

31         Internet-Drafts are working documents of the Internet Engineering
32         Task Force (IETF).  Note that other groups may also distribute
33         working documents as Internet-Drafts.  The list of current Internet-
34         Drafts is at https://datatracker.ietf.org/drafts/current/.

36         Internet-Drafts are draft documents valid for a maximum of six months
37         and may be updated, replaced, or obsoleted by other documents at any
38         time.  It is inappropriate to use Internet-Drafts as reference
39         material or to cite them other than as "work in progress."

41         This Internet-Draft will expire on 4 October 2023.

43      Copyright Notice

45         Copyright (c) 2023 IETF Trust and the persons identified as the
46         document authors.  All rights reserved.

48         This document is subject to BCP 78 and the IETF Trust's Legal
49         Provisions Relating to IETF Documents (https://trustee.ietf.org/
50         license-info) in effect on the date of publication of this document.
51         Please review these documents carefully, as they describe your rights
52         and restrictions with respect to this document.  Code Components
53         extracted from this document must include Revised BSD License text as
54         described in Section 4.e of the Trust Legal Provisions and are
55         provided without warranty as described in the Revised BSD License.

57      Table of Contents

59         1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
60           1.1.  Environment and use . . . . . . . . . . . . . . . . . . .   4
61           1.2.  Transporting information  . . . . . . . . . . . . . . . .   5
62           1.3.  Securing information  . . . . . . . . . . . . . . . . . .   7
63           1.4.  Defined-trust Communications Domains  . . . . . . . . . .   8
64           1.5.  Current status  . . . . . . . . . . . . . . . . . . . . .   9
65         2.  DeftT and Defined-trust Communications  . . . . . . . . . . .  10
66           2.1.  Inside DeftT  . . . . . . . . . . . . . . . . . . . . . .  11
67           2.2.  syncps: a set reconciliation protocol . . . . . . . . . .  12
68           2.3.  Formats of DeftT Communications . . . . . . . . . . . . .  13
69             2.3.1.  Publications  . . . . . . . . . . . . . . . . . . . .  13
70             2.3.2.  Certificates  . . . . . . . . . . . . . . . . . . . .  15
71             2.3.3.  cState  . . . . . . . . . . . . . . . . . . . . . . .  15
72             2.3.4.  cAdd  . . . . . . . . . . . . . . . . . . . . . . . .  16
73           2.4.  Interface between application and network interface . . .  17
74           2.5.  Schema-based information movement . . . . . . . . . . . .  19
75           2.6.  Congestion control  . . . . . . . . . . . . . . . . . . .  21
76         3.  Defined-trust management engine . . . . . . . . . . . . . . .  22
77           3.1.  Communications schemas  . . . . . . . . . . . . . . . . .  22
78           3.2.  A schema language . . . . . . . . . . . . . . . . . . . .  23
79         4.  Certificates and identity bundles . . . . . . . . . . . . . .  26
80           4.1.  Obviate CA usage  . . . . . . . . . . . . . . . . . . . .  27
81           4.2.  Identity bundles  . . . . . . . . . . . . . . . . . . . .  28
82         5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  30
83           5.1.  Secure Industrial IoT . . . . . . . . . . . . . . . . . .  30
84           5.2.  Secure access to Distributed Energy Resources (DER) . . .  31
85         6.  Using Defined-trust Communications without DeftT  . . . . . .  33
86         7.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . .  33
87         8.  Security Considerations . . . . . . . . . . . . . . . . . . .  35
88         9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  38
89         10. Normative References  . . . . . . . . . . . . . . . . . . . .  38
90         11. Informative References  . . . . . . . . . . . . . . . . . . .  38
91         Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  45
92         Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  45

94      1.  Introduction

96         Decades of success in providing IP connectivity over any physical
97         media ("IP over everything") has commoditized IP-based
98         communications.  This makes IP an attractive option for Internet of
99         Things (IoT), Industrial Control Systems (ICS) and Operational
100        Technologies (OT) applications like building automation, embedded
101        systems and transportation control, that previously required
102        proprietary or analog connectivity.  For the energy sector in

Nit: One or more references for OT networking technologies would be useful here.

103        particular, the growing use of Distributed Energy Resources (DER)
104        like residential solar has created interest in low cost commodity
105        networked devices but with added features for security, robustness
106        and low-power operation [MODOT][OPR][CIDS].  Other emerging uses
107        include connecting controls and sensors in nuclear power plants and
108        carbon capture monitoring [DIGN][IIOT].

Nit: Move [DIGN] after nuclear plant to keep references local to what they
refer to.

110        While moving to an IP network layer is a major advance for OT,
111        current Internet transport options are a poor match to its needs.
112        TCP generalized the Arpanet transport notion of a packet "phone call"
113        between two endpoints into a generic, reliable, bi-directional
114        bytestream working over IP's stateless unidirectional best-effort
115        delivery model.  Just as the voice phone call model spawned a global
116        voice communications infrastructure in the 1900s, TCP/IP's two-party
117        packet sessions are the foundation of today's global data
118        communication infrastructure.  But "good for global communication"
119        isn't the same as "good for everything".  OT applications tend to be
120        localized and communication-intensive with a primary function of
121        coordination and control and communication patterns that are many-to-
122        many.  Implementing many-to-many applications over two-party
123        transport sessions changes the configuration burden and traffic
124        scaling from the native media's O(_n_) to O(_n_^2) (see Section 1.2).
125        Further, as OT devices have specific, highly prescribed roles with
126        strict constraints on "who can say what to which", the opacity of
127        modern encrypted two-party sessions can make it impossible to enforce
128        or audit these constraints.

Nit: paragraph too long. Split.

Major: 125-128: An end-to-end security pundit would say that you can not trust
the network for role-based access control, but that you need to embody that in
appropriate keying/credentials on the communicating systems. Aka: I think you
need to make a stronger explanatory argument for the network being some form of
trusted party to be responsible for at least part of communications policies.
But its not even clear to me from the following text whether you really want
that. So i wonder if this text is a redundant complaint.

130        This memo describes a new transport protocol, Defined-trust Transport
131        (DeftT) for Limited Domains [RFC8799] in which multipoint
132        communications are enabled through use of a named collection
133        abstraction and secured by an integrated trust management engine.
134        DeftT employs multicast (e.g., IPv6 link-local [RFC4291]), a
135        distributed set reconciliation PDU transport, a flexible pub/sub API,
136        chain-of-trust membership identities, and secured rules that define
137        the local context and communication constraints of a deployment in a
138        declarative language.  These rules are used by DeftT's runtime trust
139        management engine to enforce adherence to the constraints.  The
140        resulting system is efficient, secure and scalable: communication,
141        signing and validation costs are constant per-publication,
142        independent of the richness and complexity of the deployment's
143        constraints or the number of entites deployed.  Like QUIC, DeftT is a
144        user-space transport protocol that sits between an application and a
145        system-provided transport like UDP or UDP multicast (see Figure 1).

147        (Artwork only available as svg: figs/defttlayer-rfc.svg)

149                        Figure 1: DeftT's place in an IP stack

151        Device enrollment consists of configuring a device with _identity
152        bundles_ that contains the trust anchor certificate, a compact and
153        secured copy of the communication rules, and a membership identity
154        (for domain communications) which comprises all the certs in its
155        signing chain (which can be used to confer attributes) terminated at
156        the trust anchor.  The secret key corresponding to the leaf

nit: If this secret key is meant to be the private key of a public key pair,
then please write private key. Else it may be useful to elaborate what your
other form of secret key tied to a certificate you are thinking of.

157        certificate of the identity should be securely configured while the
158        security of the identity bundle can be deployment-specific.  The

nit: also not clear to me what security you are referring to. Maybe include a
short example.

159        identity chains of all communicating members share a common trust
160        anchor and the rules that define legal signing chains, so the bundle

minor: Not sure if the constraint to a single trust anchor does not limit the
solution in case of mergers, aquisitions, legal oversight entities and other
cases. I went through some rework in rfc8994 to use "common set of trust
anchor(s)" or the like to be flexible enough.

nit: legal as in "permitted by DefT", or by some other (legal) entity
(deployment environment/country/.. rules ?). Prefer not to use the term legal
unless it's the latter.

161        suffices for a member to authenticate and authorize communication
162        from peers and vice-versa.  New members can join and communicate
163        without labor intensive and error-prone device-to-device association
164        configuration.

minor: Are you addressing revocation procedures ?

166     1.1.  Environment and use

168        Due to physical deployment constraints and the high cost of wiring,
169        OT networks preferentially use radio as their communication medium.
170        Use of wires is impossible in many installations (untethered Things,
171        adding connected devices to home and infrastructure networks,
172        vehicular uses, etc.).  Wiring costs far exceed the cost of current
173        System-on-Chip Wi-Fi IoT devices and the cost differential is
174        increasing [WSEN][COST].  For example, the popular ESP32 is a
175        32bit/320KB SRAM RISC with 60 analog and digital I/O channels plus
176        complete 802.11b/g/n and bluetooth radios on a 5mm die that consumes
177        70uW in normal operation.  It currently costs $0.13 in small
178        quantities while the estimated cost of pulling cable to retrofit
179        nuclear power plants is presently $2000/ft [NPPI].

major: I think this whole paragraph is way too broadly one-sides in favor of
radio technologies. Radio connectivity has a lot of downsides, especially in
the face of machinery that introduces frequency disturbances ("motors",
"microwaves",...) such as in industrial environments, transportation. And your
example does not include the OPEX for powering the device, such as swapping of
battery, or worse yet, swapping the device because of non-replaceable
batteries. What you describe is just one side of a larger coin. The other side
of the coin is that if you are using wires to power devices, then those wires
can and will also provide networking. There is a whole area of work evolving
for 2-wire ethernet for example to do exactly that. Not to speak of all the
places where PoE already is successful, including in OT.

181        OT applications are frequently Limited Domain with communications

nit: i am actually not a fan of "limited domain", but would have preferred
if we would have sticked to the prior established "controlled domains",
"controlled networks" or the like. For example, a country wide trackside OT
network could (and does) span tenths of thousands of miles. What again is
"limited" here ? Aka: I would prefer to not see a proliferation of "limited"
because it does introduce incorrect associations.

182        that are local, have a many-to-many pattern, and use application-
183        specific identifiers ("topics") for rendezvous.  This fits the

nit: arguably, DNS and even more so DNS-SD are also application specific
identifiers, so i have a hard time considering that to be a significant
distinguisher for controlled networks vs. the Internet. The maybe more fitting
broader classification of controlled network is that the application owner has
a larger say about the functionalities in the network than this is the case for
the public Internet, aka: stronger vertical integration.

184        generic Publish/Subscribe communications model ("pub/sub") and, as
185        table 1 in [PRAG] shows, nine of the eleven most widely used IoT
186        protocols use a topic-based pub/sub transport.  For example MQTT, an
187        open standard developed in 1999 to monitor oil pipelines over
188        satellite [MQTT][MHST], is now likely the most widely used IoT
189        protocol (https://mqtt.org/use-cases/ (https://mqtt.org/use-cases/)).

nit: What is an "IoT protocol" ? maybe "protocol primary developed for IoT" ?
(is IP an IoT protocol ?

191        Microsoft Azure, Amazon AWS, Google Cloud, and Cloudflare all offer
192        hosted MQTT brokers for collecting and connecting sensor and control
193        data in addition to providing local pub/sub in buildings, factories
194        and homes.  Pub/sub protocols communicate by using the same topic but
195        need no knowledge of one another.  These protocols are typically

nit: reshuffle. Move Pub/sub explanation here into 186, follow with MQTTT
example, finish with big cloud player list ?

196        _implemented_ as an application layer protocol over a two-party
197        Internet transports like TCP or TLS which require in-advance
198        configuration of peer addresses and credentials at each endpoint and
199        incur unnecessary communications overhead Section 1.2.

nit: maybe "are today typically". One may remember that the most successful bus
protocols in IP land such as TIBCO bus where originally using IP Multicast ASM,
and only evolved away from that because (censured #$%%$^$^ complaints about
router vendors). But likewise there is ICN/CCN, which i think would be worth to
mention at least.

201     1.2.  Transporting information

203        The smart lighting example of Figure 2 illustrates a topic-based pub/
204        sub application layer protocol in a wireless broadcast subnet.  Each
205        switch is set up to do triple-duty: one click of its on/off paddle
206        controls some particular light(s), two clicks control all the lights
207        in the room, and three clicks control all available lights (five
208        kitchen plus the four den ceiling).  Thus a switch button push may
209        require a message to as many as nine light devices.  On a broadcast
210        physical network each packet sent by the switch is heard by all nine
211        devices.  IPv6 link-level multicast provides a network layer that can

nit: "broadcast physical network" - probably better to say "broadcast
transmission medium". But there also seems to be some lead-in missing, such
that those replicated unicast messages are highly undesiragle for e.g.: energy
consumption purposes. Which then goes back to why not use a broker, which is
what most IoT systems do these days (and most don't understand its downside),
aka: you're skipping over steps that people new to the matter may not easily be
able to follow

212        take advantage of this but current IP transport protocols cannot.

nit: RFC3208, RFC5740 ? We had a whole IETF WG on reliable multicast transport
protocols, so there should be some explanation of what new work is needed here.

213        Instead, each switch needs to establish nine bi-lateral transport

nit: light-switch

214        associations in order to send the published message for all lights to
215        turn on.  Communicating devices must be configured with each other's
216        IP address and enrolled identity so, for _n_ devices, both the
217        configuration burden and traffic scale as O(_n^2_).  For example,

nit: s/as/is/

218        when an "_all_" event is triggered, every light's radio will receive
219        nine messages but discard the eight determined to be "not mine."  If
220        a device sleeps, is out-of-range, or has partial connectivity,
221        additional application-level mechanisms have to be implemented to
222        accommodate it.

major: The additional complexity for reliability would not be lower with
multicast/broadcast. Most people involved in the RMT process would rather claim
that it is quite complex and likely one of the reasons for little adoption of
RMT protocols. Aka: as much as i dislike the argument, most people would say
unicasting makes reliability (retransmissions) easier! As proof i could try to
find all the docs we had to mention how the industry transmits multicast over
WiFi: by converting it to unicast.

nit: given how you're only starting to explain broker next, maybe reshuffle the
lager text to unicast -> broker -> multicast. Otherwise it seems you're
sprinkling multicast without explaining it well..

224        (Artwork only available as svg: figs/iotDeftt-rfc.svg)

226                       Figure 2: Smart lighting use of Pub/Sub

228        MQTT and other broker-based pub/sub approaches mitigate this by
229        adding a _broker_ where all transport connections terminate
230        (Figure 3).  Each entity makes a single TCP transport connection with
231        the broker and tells the broker the topics to which it subscribes.
232        Thus the kitchen switch uses its single transport session to publish
233        commands to topic kitchen/counter, topic kitchen or all.  The kitchen
234        counter light uses its broker session to subscribe to those same
235        three topics.  The kitchen ceiling lights subscribe to topics kitchen
236        ceiling, kitchen and all while den ceiling lights subscribe to topics
237        den ceiling, den and all.  Use of a broker reduces the configuration
238        burden from O(_n_^2) to O(_n_): 18 transport sessions to 11 for this
239        simple example but for realistic deployments the reduction is often
240        greater.  There are other advantages: besides their own IP addresses

nit: paragraph too long, split here ?

241        and identities, devices only need to be configured with those of the
242        broker.  Further, the broker can store messages for temporarily
243        unavailable devices and use the transport session to confirm the
244        reception of messages.  This approach is popular because the pub/sub
245        application layer protocol provides an easy-to-use API and the broker
246        reduces configuration burden while maintaining secure, reliable
247        delivery and providing short-term in-network storage of messages.
248        Still the broker implementation doubles the per-device configuration
249        burden by adding an entity that exists only to implement transport
250        and traffic still scales as O(_n^2_), e.g., any switch publishing to
251        all lights results in ten (unicast) message transfers over the wifi
252        network.  Further, the broker introduces a single point of failure
253        into a network that is richly connected physically.

nit: I'd put single point of failure as he top reason.
Auto-selection/discovery/redundancy as secondary reasons (complexity).

255        (Artwork only available as svg: figs/iotMQTT-rfc.svg)

257          Figure 3: Brokers enable Pub/Sub over connection/session protocols

259        Clearly, a transport protocol able to exploit a physical network's
260        broadcast capabilities would better suit this problem.  (Since

minor: as much as i am a fan of multicast, one may want to understand, that this
again only captures the realities of on specific type of transmission media or
network setups. For example the further down we go on the MIMO trail, the more
WiFi experts will tell you that multicasting is extremely energy intensive
because you don't know whether a receiver is (direction) and you need to reach
all of them (power level). Likewise, in mesh networks, mesh nodes also need to
forward broadcast packets unnecessary, etc. pp. Unless you want to discuss any
such pro/cons maybe just present the muticast approach as a valid option
without judgement.

261        unicast is just multicast restricted to peer sets of size 2, a
262        multicast transport handles all unicast use cases but the converse is
263        not true.)  In the distributed systems literature, communication

minor: "If the transmission media or network is based on broadcsast and no
further ooptimizations are possible for unicast transmission, then... (unicast
is just a restriction of...)."

264        associated with coordinating shared objectives has long been modeled
265        as _distributed set reconciliation_ [WegmanC81][Demers87].  In this

nit: that sounds like opening a new book here. Paragraph break on line 263 ?

266        approach, each domain of discourse is a named set, e.g.,
267        _myhouse.iot_. Each event or action, e.g., a switch button press, is
268        added as a new element to the instance of _myhouse.iot_ at its point
269        of origin then the reconciliation process ensures that every instance
270        of _myhouse.iot_ has this element.  In 2000, [MINSKY03] developed a
271        broadcast-capable set reconciliation algorithm whose communication
272        cost equaled the set instance _differences_ (which is optimal) but
273        its polynomial computational cost impeded adoption.  In 2011, [DIFF]
274        used Invertible Bloom Lookup Tables (IBLTs) [IBLT][MPSR] to create a
275        simple distributed set reconciliation algorithm providing optimal in
276        both communication and computational cost.  DeftT uses this algorithm

nit: another paragraph here

minor: Might be helpful to spend one or more sentences to explain the concept.
Such as "more general solutions for the best communication paradigms are
possible by abstracting the problem away from message exchange/propagation and
distribution over to the concept of shared state and then determining the
optimum communications method from those sharing targets. this is called
"distributed set reconciliation".

277        (see Section 2.2) and takes advantage of IPv6's self-configuring link
278        local multicast to avoid all manual configuration and external
279        dependencies.  This restores the system design to Figure 2 where each
280        device has a single, auto-configured transport that makes use of the
281        broadcast radio medium without need for a broker or multiple
282        transport associations.  Each button push is broadcast exactly once
283        to be added to the distributed set.

minor: some pointer / explanation to how the algorithm deals with sender or
receiver loss of such a message would be be nice.

285     1.3.  Securing information

287        Conventional session-based transports combine multiple publications
288        with independent topics and purposes under a single session key,
289        providing privacy by encrypting the sessions between endpoints.  The

nit: If pub/sub communication is carried across conventional ...
Otherwise it sounds as if pub/sub is mandatory for session based transport.

290        credentials of endpoints (e.g., a website) are usually attested by a
291        third party certificate authority (CA) and bound to a DNS name; each

nit: enpoints communicating across the Internet
nit: add reference to WebPKI.

minor: aka: binding to DNS is not common for private PKI, such as what we
predominantly use in controlled networks (limited domains). Such as BRSKI, ACP
or other ANIMA RFCs.. (and most non-IETF use of PKI either).

292        secure transport association requires the exchange of these
293        credentials which allows for secure exchange of a nonce symmetric
294        key.  In Figure 3 each transport session is a separate security
295        association where each device needs to validate the broker's
296        credential and the broker has to validate each device's.  This
297        ensures that transport associations are between two enrolled devices
298        (protecting against outsider and some MITM attacks) but, once the
299        transport session has been established there are no constraints
300        whatsoever on what devices can say.  Clearly, this does not protect
301        against the insider attacks that currently plague OT, e.g., [CHPT]
302        description of a lightbulb taking over a network.  For example, the
303        basic function of a light switch requires that it be allowed to tell
304        a light to turn on or off but it almost certainly shouldn't be
305        allowed to tell the light to overwrite its firmware (fwupd), even
306        though "on/off" and "fwupd" are both standard capabilities of most
307        smart light APIs.  Once a TLS session is established, the transport

major: I thought all better pub/sub have according policy options on the
brokers. minor: You do not mention that you need to trust the broker and that
the broker is also a single point of attack.

308        handles "fwupd" publications _the same way_ as "on/off" publications.
309        Such attacks can be prevented using trust management that operates
310        per-publication, using rules that enable the "fwupd" from the light
311        switch to be rejected.  Combining per-publication trust decisions
312        with many-to-many communications over broadcast infrastructure
313        requires per-publication signing rather than session-based signing.

major: YOU're also eliminating the trusted third-party (broker). So arguably,
end-to-end signing is benficial independent of the communication method.

315        Securing each publication rather than the path it arrives on deals

nit: /path/session/

316        with a wider spectrum of threats while avoiding the quadratic session
317        state and traffic burden.  In OT, valid messages conform to rigid
318        standards on syntax and semantics
319        [IEC61850][ISO9506MMS][ONE][MATR][OSCAL][NMUD][ST][ZCL] that can be
320        combined with site-specific requirements on identities and
321        capabilities to create a system's communication rules.  These rules
322        can be employed to secure publications in a trust management system
323        such as [DLOG] where each publisher is responsible for supplying all
324        of the "who/what/where/when" information needed for each subscriber
325        to _prove_ the publication complies with system policies.

minor: a simple example would help. I guess the whole point is that subscribers
are pre-fed with rulea bout what exact type of messages each specific publisher
is allowed to send that is relevant to be received by this subscriber and
because of the end-to-end authentication of publications the subscriber can
hence verify the permissibility of the publication ? If true, then this is also
the type of language i would recommend.

nit: not sure if "prove" is the best word re. "verify"...

327        Instead of vulnerable third-party CAs [W509], sites employ a local
328        root of trust and locally created certificates.  When the

minor: The reference is not specific to third party PKI downside, so the
sentence is somewhat of a fake argument. You are also not making a specific
point about what properties in a PKI you think you want to motivate your ask
for a local CA. What would you miss if you simply deleted this sentence ?

329        communication rules are expressed in a _declarative_ language [DLOG],
330        they can be validated for consistency and completeness then converted
331        to a compact runtime form which can be authorized and secured via
332        signing with the system trust anchor.  This _communication schema_
333        can be distributed as a certificate, then validated using on-device

minor: what does that mean ? Stuff the whole runtime form as new attributes into
a certificate ? How large would that be ? Sounds excessive. Why not simply a
signed document ?

334        trusted enclaves [TPM][HSE][ATZ] as part of the device enrollment
335        process.  In DeftT's publication-based transport, the schema is used

minor: any examples of trusted enclaves on ESP32 ? I have only seen those
in largrer devices, hopefully not a tall order for downscaling.

major:  Not clear
why this has to be tied to device enrolment. I am guilty of stuffing additional
information into certifictes (RFC8994) to "abuse" automated enrollment, because
we just do not have any other form of communications than that automated
enrollment protocol (RFC8995) at the time we need it, but we had to fight long
and hard for that and only got away with it, because its very little information
and its directly tied to the identity of the device and will not change during
the lifetime of the device. I can not see this to be true for communication
policies within e.g.: a manufacturing plant, at least not when i use industry
4.0 agile manufacutring, where the policies for communications could change in
the order of weeks. YOu don't want to do cert renewal just for that (IMHO). Of
course, you're not targeting IETF standard, but still...

336        to both construct and validate publications, guaranteeing that _all_
337        parts of the system _always_ conform to and enforce the same rules,
338        even as those rules evolve to meet new threats (more in Section 3.1).
339        DeftT embeds the trust management mechanism described above directly
340        in the publish and subscribe data paths as shown below:

342        (Artwork only available as svg: figs/trustElements-rfc.svg)

344                    Figure 4: Trust management elements of DeftT.

346        This approach extends LangSec's [LANG] "be definite in what you
347        accept" principle by using the authenticated common ruleset for belt-
348        and-suspenders enforcement at both publication and subscription
349        functions of the transport.  If an application asks the Publication

nit: explain or provide reference for "belt-and-suspenders" term if you want to
keep it. Both LangSec and this term seem to be unsolicited in this context. Aka:
they only help to confuse readers that don't know them. Easier to explicitly
explain the technical value propositions in a document like this (this is not a
research paper!).

350        Builder to publish something and the schema shows it lacks
351        credentials, an error is thrown and nothing is published.

mayor: The scheme does seem to trust the local application though, because does
not validate on publication. I think untrusted applications are a common
problem, so i would recommend to have in the publication builder also the
optional validation component. If thats already implied, that  should be
explained.

Most common reason for untrusted is unexpectedly broken.

352        Independently, the Publication Validator ignores publications that:

354        *  don't have a locally validated, complete signing chain for the
355           credential that signed it
356        *  the schema shows its signing chain isn't appropriate for this
357           publication
358        *  have a publication signature that doesn't validate

mayor: it would be good if the picture would show where the identity credentials
are accessed from. I would guess that the device specific application code
does NOT have the ability to sign, but that the publication builder does
that. Aka: paint a cert beside the pub builder block, and the trust-anchors
beside the validator for example to clarify this.

360        Note that since an application's subscriptions determine which
361        publications it wants, only certificates from chains that can sign
362        publications matching the subscriptions need to be validated or
363        retained.  Thus a device's communication state burden and computation
364        costs are a function of how many different things are allowed to talk
365        to it but _not_ how many things it talks to or the total number of
366        devices in the system.  In particular, event driven, publish-only
367        devices like sensors spend no time or space on validation.  Unlike
368        most 'secure' systems, adding additional constraints to schemas to
369        reduce attack surface results in devices doing _less_ work.

371     1.4.  Defined-trust Communications Domains

373        A Defined-trust Communications Limited Domain (or simply, _trust
374        domain_) is a Limited Domain where all the members communicate via a
375        DeftT Figure 5 and are configured with the same trust anchor, schema,
376        a schema-conformant DeftT identity cert chain that terminates at the
377        trust anchor and the secret key corresponding to the identity chain's
378        leaf cert.  The particular rules for any deployment are application-

nit: this is a german sentence (too long). It somehow reads as if there is a
single secret key / leaf cert. "where each member" ... "and each member is
configured", and a unique per member public key pair... Something like that to
be precise.

379        specific (e.g., Is it home IoT or a nuclear power plant?) and site-
380        specific (specific form of credential and idiosyncrasies in rules)
381        which DeftT accommodates by being invoked with a ruleset (schema)
382        particular to a deployment.  We anticipate that the efforts to create
383        common data models (e.g., [ONE]) for specific sectors will lead to
384        easier and more forms-based configuration of DeftT deployments.

386        A trust domain is perimeterless and may operate over one or more
387        subnets, sharing physical media with non-member entities.  Member
388        entities throughout the domain publish and subscribe to its topics
389        using Publication Builders and Validators as shown in Figure 4.
390        These Publications become the elements of a set, or named collection,
391        that is confined to each subnet.  DeftT uses a distributed set
392        reconciliation protocol on _each_ collection and _each_ subnet
393        independently.  Every DeftT maintains at least two collections:
394        *pubs* for application Publications and *cert* where identity bundle
395        certs are published.  Figure 5

397        (Artwork only available as svg: figs/trustdomain-rfc.svg)

399                                Figure 5: Trust domain

401        Trust domains are extended across physically separated subnets,
402        subnets using different media and/or subdomains on the same subnet
403        (see Section 2.5) by using *Relays* that have a DeftT in each subnet
404        and pass Publications between subnets as long as they are valid at
405        the receiving DeftT Figure 6.  Since set reconciliation does not
406        accept duplicates, Relays are powerful elements in creating efficient
407        configuration-free meshes.  The subnets of the figure could be
408        different colocated media (e.g. bluetooth, wifi, ethernet) or may be
409        physically distant.  The triangle Relay-only subnet can be carried
410        over a unicast link.  The set reconciliation protocol ensures that
411        items only transit a subnet once: an item must be specifically
412        requested in order to be transmitted.  More Relay discussion is in
413        Section 2.5 and Section 5.

415        (Artwork only available as svg: figs/relayedtrustdomain-rfc.svg)

417                            Figure 6: Relayed trust domain

minor: i really don't like that figure because it doesn't give any idea
that publications are forwarded by relays. I would suggest to paint a picture
that starts off as if it was a wired network with relays like routers connecting
to multiple LANs, and then if you really insist replace the LAN symbol (line)
with something dotted or cloudy or the like to express a radio subnet.

419     1.5.  Current status

421        An open-source Defined-trust Communications Toolkit [DCT] with an
422        example implementation of DeftT is maintained by the corresponding
423        author's company.  [DCT] has examples of using DeftT to implement
424        secure brokerless message-based pub/sub using UDP/IPv6 multicast and
425        unicast UDP/TCP and include extending a Trust Domain via a unicast

nit: UDP/TCP work without IPv6 ? (just for consistency, incude IPv6 here as
well IMHO, unless its IPv6 and IPv4, which would be worth to explain too).

426        connection or between two broadcast network segments.  Working
427        implementations and performance improvements are occasionally added
428        to the repository.

nit: use subsections here to better structure ? Above is common code, next is
one specific application ?

430        Massive build out of the renewable energy sector is driving
431        connectivity needs for both monitoring and control.  Author King's
432        company, Operant, is currently developing extensions of DeftT in a
433        mix of open-source and proprietary software tailored for commercial
434        deployment in support of distributed energy resources (DER).  Current
435        small scale use cases have performed well and expanded usage is
436        planned.  Pollere is also working on home IoT uses.  Our development
437        philosophy is to start from solving useful problems with a well-
438        defined scope and extend from there.  As the needs of our use cases
439        expand, the Defined-trust communications framework will evolve with
440        increased efficiencies.  DeftT's code is open source, as befits any
441        communications protocol, but even more critical for one attempting to
442        offer security.  DCT itself makes use of the open source
443        cryptographic library libsodium [SOD] and the project is open to
444        feedback on potential security issues as well as hearing from
445        potential collaborators.

447        The well-known issues with 802.11 multicast [RFC9119] can make DeftT
448        less efficient than it should be.  Target OT deployments primarily

minor: still not clear up to this point if DefT does have reliable multicasting
itself in the face of packet loss (which cheap or even indstrial 802.11 APs may
have)
 or expects 100% reliable link-local multicast... No description of
 retransmissions
made so far.

449        use smaller packet sizes and DeftT's set reconciliation provides
450        robust delivery that currently mitigates these concerns.  DeftT use

451        may become another force for improved multicast on 802.11, joining
452        the critical network infrastructure applications of neighbor
453        discovery, address resolution, DHCP, etc.

minor: Uhmmm... my impression is rather that everybody workin on those multicast
bits in subnet multicast rather wants to run away from using link-local
multicast or reduce it's use. Not that i like that, but it makes your optimism
a bit out of left field. Maybe rathre make sure your solutiopn does have the
elemednts (did i mention retransmission) to work over crappy radio subnets.

455        Cryptographic signing takes most of the application-to-network time
456        in DeftT.  Though not prohibitively costly, increased use of signing
457        in transports may incentivize creation of more efficient signing
458        algorithms.

major: Well, this seems to be al asymmetric signing. I did start to look into
thre costs of that as well. TU Hamburg did have a nice comparison of
performance of various constrained node types (mostly ARM based if i remember).
YOu certainly should explicitly acknowledge the cost of asymmetric signing more
explicitly. Its a cost of doing future business and the faster the industry
accepts that the faster it will get optimized.

460     2.  DeftT and Defined-trust Communications

462        DeftT synchronizes and secures communications between enrolled
463        members of a Limited Domain [RFC8799].  DeftT's multi-party
464        synchronized collections of named, schema-conformant Publications
465        contrast with the bilateral session of TCP or QUIC where a source and
466        a destination coordinate with one another to transport
467        undifferentiated streams of information.  DeftTs in a trust domain
468        may hold different subsets of the collection at any time (e.g.,
469        immediately after entities add elements to the collection) but the
470        synchronization protocol ensures all converge to holding the complete
471        set of elements within a few round-trip-times following the changes.

473        Applications use DeftT to add to and access from a collection of
474        Publications.  DeftT enforces "who can say what to which" as well as
475        providing required integrity, authenticity and confidentiality.
476        Transparently to applications, a DeftT both constructs and validates
477        all Publications against its schema's formal, validated rules.  The
478        compiled binary communications schema is distributed as a trust-root-
479        signed certificate and that certificate's thumbprint (see
480        Section 2.3.2 and Section 7) _uniquely_ identifies each trust domain.

nit: Seems like a lot of informal repetition of text from the introduction
section. Would suggest to go through all the section 2 and delete
duplications/repetitions, unless there is a good reason not to.

481        Each DeftT is configured with the trust anchor used in the domain,
482        the schema cert, and its own credentials for membership in the
483        domain.  To communicate, DeftTs must be in the same domain.  Identity

nit: you didn't really define what you mean with "domain". Should also be DefT
domain, and be defined as the collection of nodes with transitive connectivity
that share the same (set of) trust anchors and certificates signed by them.
We've done this all quite formally for RFC8994 (ACP domain etc..).

484        credentials comprise a unique private identity key along with a
485        public certificate chain rooted at the domain's trust anchor.
486        Certificates in identity chains are specified in the schema and

nit: not clear what line 486 says. Rephrase or give example

487        contain the attributes granted to the identity.  Thus, attributes are
488        stored in the identity *not* on an external server.

nit: add (forward ?) reference to attributes.

490        Each member publishes its credentials to the certificate collection
491        in order to join the domain.  DeftT validates credentials as a

nit: point to definition of "(certificate) collection" in your spec.

minor: Sounds interesting to illustrate the flow of messages when a particular
member1 first receives a publication to a topic it is interested in that is
published from a member2 that member1 does not have the certificate for. Seems
as if member1 would then first need to subdscribe to the member2 certificate
publication and could only afterwards continue to validate the other publication
from member2. But then following on there likely is some form of caching of
the publication ? Is there spec as to how a memory limited subscriber does that
?

492        certificate chain against the schema and does not accept Publications
493        without a fully validated signer.  This unique approach enables fully
494        distributed policy enforcement without a secured-perimeter physical
495        network and/or extensive per-device configuration.  DeftT can share
496        an IP network with non-DeftT traffic as well as DeftT traffic of a
497        different omain.  Privacy via AEAD encryption is automatically

nit: more benefit explanations, partially repeated from intro. Not spec text.

nit: AEAD expand on first use, maybe terminology section and/or reference.

498        handled within DeftT if selected in the schema.

500        (Artwork only available as svg: figs/transportBD0v2-rfc.svg)

502                   Figure 7: DeftT's interaction in a network stack

504        Figure 7 shows the data flow in and out of a DeftT.  DeftT uses its
505        schema to package application information into Publications that are
506        added to its local view of the collection.  Application information
507        is packaged in Publications which are carried in cAdd PDUs that are
508        used along with cState PDUs to communicate about and synchronize
509        Collections. cStates are used to report the state of the local
510        collection; cAdds carry Publications to other members that need them.
511        These PDUs are broadcast on their subnet (e.g., UDP multicast).

minor: Seems more like an example than part of a spec. Maybe move into
introduction.

513     2.1.  Inside DeftT

515        DeftT's reference implementation [DCT] is organized in functional
516        library modules that interact to prepare application-level

nit: what is "functional library module" ? Remove functional ?

517        information for transport and to extract application-level
518        information from packets, see Figure 8.  Extensions and alternate
519        module implementations are possible but the functionality and
520        interfaces must be preserved.  Internals of DeftT are completely
521        transparent to an application and the reference implementation is
522        efficient in both lines of code and performance.  The schema

nit: any metric/examples to support efficiency claims ?

523        determines which modules are used.  A DeftT participates in two
524        required collections and _may_ participate in others if required by
525        the schema-designated signature managers.  One of the required

nit: introduction of term signature managers without explanation or forward
reference.

526        collections, descriptive collection name component *pubs*, contains
527        application Publications (see Table 2).  The other required
528        collection, *cert*, manages the certificates of the trust domain.
529        Specific signature managers _may_ require group key distribution in
530        descriptively named collection *keys*.

nit: reference to unkown/unexplained term group keys without explanation or
forward reference.

532        (Artwork only available as svg: figs/DeftTmodules-rfc.svg)

534                          Figure 8: Run-time library modules

536        A _shim_ serves as the translator between application semantics and
537        the named information objects (Publications) whose format is defined
538        by the schema.  The *syncps* module is the set reconciliation
539        protocol used by DeftT (see Section 2.2).  New signature managers,
540        distributors, and face modules may be added to the library to extend
541        features.  More detail on each module can be found at [DCT] in both
542        code files and documents.

nit: distributor and face referenced without explanation or forward reference
in the document. Simply referring to a big external document [DCT] is not a
good style when one wants to understand the core modules of DefT. Can't be that
difficult to start out with a list of modules referred to by this cdocument,
each with a short paragraph/synopsis of function and forward references as
necessary.

544        The signing and validation modules (_signature managers_) are used
545        for both Publications and cAdds.  Following good security practice,
546        DeftT's Publications are constructed and signed _early_ in their
547        creation, then are validated (or discarded) early in the reception
548        process.The _schemaLib_ module provides certificate store access
549        throughout DeftT along with access to _distributors_ of group keys,
550        Publication building and structural validation, and other functions
551        of the trust management engine.  This organization of interacting
552        modules is not possible in a strictly layered implementation.

nit: Not clear what the purpose is of the last sentence. I like good rants about
non-working archteictures, but who would want to consider DefT modules to be
part of different layers, and if so which modules into which layer ? Unless you
want to elaborate to bring that point home, maybe just delete sentence.

554     2.2.  syncps: a set reconciliation protocol

556        DeftT requires a method or protocol that keeps collections
557        synchronized, where the collection a set and the Publications are the

nit: where collections are set of Publications ?

nit: Think of some logic for capitalization. Why are Publications capitalized
but collections not ?

558        elements of the set.  The *syncps* protocol uses IBLTs
559        [DIFF][IBLT][MPSR] to solve the multi-party set-difference problem
560        efficiently without the use of prior context and with communication
561        proportional to the size of the difference between the sets being
562        compared.  Syncps announces its _collection state_ (set of currently
563        known Publications) by sending a cState PDU containing an IBLT.  The
564        cState serves as a query for additional data that isn't reflected in
565        its local state.  Receipt of a cState performs three simultaneous
566        functions: (1) announces new Publications, (2) notifies of
567        Publications that member(s) are missing and (3) acknowledges
568        Publication receipt.  The first may prompt the recipient to share its
569        cState to get the new Publication(s).  The second results in sending
570        a cAdd PDU containing all the missing and locally available
571        Publications that fit.  The third may result in a progress
572        notification sent to other local modules so anything waiting for
573        delivery confirmation can proceed.

bail: Alas i don't have the time to try to understand this protocol in detail
right now, even though its vdery interesting. So can not comment on correctness.

nit: new subsection for IBLT/syncps explanation ?

nit: this is providing reliability which i was asking for upfront, so it would
be good to mention that explicitly avbove where i asked with forward pointers
to this section.

575        On broadcast media, syncps uses the cStates it hears to suppress
576        sending its own and listens for any cAdds that add to its cState.
577        This means that one-to-many Publications require one cState and one
578        cAdd to be sent, independently of the number of members desiring the
579        Publication (the theoretical minimum possible for reliable delivery).
580        The digest size of a cState can be controlled by Publication
581        lifetime, dynamically constructing the digest to maximize
582        communication progress [Graphene][Graphene19] and, if necessary for a
583        large network, dynamically adapting topic specificity.

585        A cAdd with new Publication(s) responds to a particular cState so a
586        receiving syncps removes that cState as a pending query (it will be
587        replaced with a new cState with the addition of the new items).  Any
588        DeftT that is missing a Publication (due to being out-of-range or
589        asleep, etc.) can receive it from any other DeftT.  A syncps will
590        continue to send cAdds as long as cStates are received that are
591        missing any of its active Publications.  This results in reliability
592        that is subscriber-oriented, not publisher-oriented and is efficient
593        for broadcast media, particularly with protocol features designed to
594        prevent multiple redundant broadcasts.

596     2.3.  Formats of DeftT Communications

598        In DeftT, information containers (i.e., Publications, cAdds, Cstate)
599        hold names, content and signatures in TLVs.  Tables 1-3 layout the
600        formats of Publications, cStates, cAdds and certificates, which are a
601        special type of Publication (where _keys_ are the information
602        carried).  Publications and cAdds use a compatible format which
603        allows them to use the same library signing/validation modules
604        (_sigmgrs_) and the same parser.  The cState/cAdd formats and
605        dynamics were originally prototyped using Named Data Networking.
606        Although the NDN code and architecture are not used in DeftT or DCT,
607        a restricted version of the NDNv3 TLV encoding is still used, with
608        TLV types from NDN's TLV Type Registry [NDNS], as is its IANA
609        assigned port number [RFC6335].

611        In Tables 1-3, the Type in level _i_ is contained within the TLV of
612        the previous level _i-1_ TLV.

614     2.3.1.  Publications

616        Publications use a Name TLV to encode the name defined in the schema.
617        A Publication is _valid_ if it starts with the correct TLV, its Name
618        validates against the schema and it contains the five required Level
619        1 TLVs in the right order (top-down in Table 1) and nothing else.
620        MetaInfo contains the ContentType (in DeftT either type Key or Blob).
621        The Content carries the named information and may be empty.
622        SignatureInfo indicates the SignatureType used to select the
623        appropriate signature manager (Figure 8).  The SignatureType for a
624        collection's Publications is specified in the schema and each
625        Publication must match it.  (A list of current types can be found in
626        [DCT] file include/dct/sigmgrs/sigmgr.hpp.)  The KeyLocator holds the
627        thumbprint (see Section 2.3.2) of the certificate that signed this
628        Publication.  If the Publication is a certificate, KeyLocator will be
629        followed by the ValidityPeriod.  Finally, SignatureValue is
630        determined by the SignatureType and its format is verified by the
631        signature manager.

633           +=======+================+================+==================+
634           | Level | Level 1        | Level 2        | Comments         |
635           | 0     |                |                |                  |
636           +=======+================+================+==================+
637           | Type  |                |                | the value 6      |
638           +-------+----------------+----------------+------------------+
639           |       | Name           |                | format specified |
640           |       |                |                | by schema        |
641           +-------+----------------+----------------+------------------+
642           |       | MetaInfo       |                |                  |
643           +-------+----------------+----------------+------------------+
644           |       |                | ContentType    | either type Key  |
645           |       |                |                | or Blob          |
646           +-------+----------------+----------------+------------------+
647           |       | Content        |                | arbitrary byte   |
648           |       |                |                | sequence; may    |
649           |       |                |                | have length 0    |
650           +-------+----------------+----------------+------------------+
651           |       | SignatureInfo  |                |                  |
652           +-------+----------------+----------------+------------------+
653           |       |                | SignatureType  | Value specified  |
654           |       |                |                | by schema        |
655           +-------+----------------+----------------+------------------+
656           |       |                | KeyLocator     | must be a        |
657           |       |                |                | thumbprint       |
658           +-------+----------------+----------------+------------------+
659           |       |                | ValidityPeriod | Only for         |
660           |       |                |                | Certificates     |
661           +-------+----------------+----------------+------------------+
662           |       | SignatureValue |                | format           |
663           |       |                |                | determined by    |
664           |       |                |                | SignatureType    |
665           +-------+----------------+----------------+------------------+

667                            Table 1: Publication format

669     2.3.2.  Certificates

671        Certificates (certs) are Publications with the ContentType set to Key
672        and both a KeyLocator and a ValidityPeriod.  DCT certs are compatible
673        with the NDN Certificate standard V2 but adhere to a stricter set of

nit: reference pls. for that standard

674        conventions to make them resistant to substitution, work factor and
675        DoS attacks.  The _only_ KeyLocator type allowed in a DCT cert is a
676        KeyDigest type that must contain the 32 byte SHA256 digest of the
677        _entire_ signing cert (including SignatureValue).  A self-signed cert
678        (such as a trust anchor) must set this digest to all zero.  This
679        digest, a cert _thumbprint_ [IOTK], is the only locator allowed in
680        _any_ signed Defined-trust object (e.g., Publications, cAdd, schemas,
681        certs) and must be present in every signed object.  A signed object
682        using any other type of locator will be considered unverifiable and
683        silently ignored.  Certificate Names use a suffix:

685          KEY/<keyID>/dct/<version>

687        where the cert's thumbprint is the keyID and its creation time is the
688        version.

minor: How does this mechanism deal with hash collisions ? useful to explain.
(publiction is list of colliding certs with same hash ?)

690        The original publisher of any signed object must ensure that that
691        _all_ certs, schemas, etc., needed to validate the object have been
692        published _before_ the object is published.  If a member receives a
693        signed object that is missing any of its signing dependencies, the
694        object should be considered unverifiable and silently ignored.  Such
695        objects must not be propagated.

697     2.3.3.  cState

699        cState and cAdds are are the PDUs exchanged with the system-level
700        transport in use (e.g., UDP) but are only used by the syncps and face
701        modules Figure 8: syncps creates cState and cAdd PDUs while the face
702        manages the protocol interaction within the trust domain.  A cState
703        PDU (see Table 2) is used to report the state of a Collection at its
704        originator.  Collections are denoted by structured names which
705        include the identifier of a particular trust domain (thumbprint of
706        its schema cert). in DeftT PDU headers.  A cState serves to inform
707        all subscribing entities of a trust domain about Publications
708        currently in the Collection, both so an entity can obtain
709        Publications it is missing and so an entity can add Publications it
710        has that are not reflected in the received cState.

712        +=========+==========+=========+====================================+
713        | Level 0 | Level 1  | Level 2 | Comments                           |
714        +=========+==========+=========+====================================+
715        | Type    |          |         | the value 5                        |
716        +---------+----------+---------+------------------------------------+
717        |         | Name     |         |                                    |
718        +---------+----------+---------+------------------------------------+
719        |         |          | Generic | trust domain id                    |
720        +---------+----------+---------+------------------------------------+
721        |         |          | Generic | descriptive collection name        |
722        +---------+----------+---------+------------------------------------+
723        |         |          | Generic | collection state (sender's view)   |
724        +---------+----------+---------+------------------------------------+
725        |         | Nonce    |         | uniquely distinguishes this        |
726        |         |          |         | cState                             |
727        +---------+----------+---------+------------------------------------+
728        |         | Lifetime |         | expiry time (ms after arrival)     |
729        +---------+----------+---------+------------------------------------+

731                                Table 2: cState format

733        A cState is _valid_ if it starts with the correct TLV and it contains
734        the three required Level 1 TLVs in the right order (top-down in
735        Table 2) and nothing else.  Its Name must start with the trust domain
736        id of the DeftT, then a descriptive Collection name (of at least one
737        component) and finally a representation of the the state of the
738        Collection at the originator.  There is no signature for a cState
739        PDU.  (The cState format is a restricted subset of an NDNv3
740        Interest.)

742     2.3.4.  cAdd

nit: would be nice instead of using a flat 2.3.x numbering to make this more
structured, e.g.: PDU vs. Certificates

744        A cAdd PDU is used by _syncps_ to add Publications to a collection
745        and carries Publications as Content. _syncps_ creates a cAdd PDU
746        after receiving a cState and only if the recipient has Publications
747        that are not reflected in the received state.  A cAdd is _valid_ if
748        it starts with the correct TLV, contains the five required Level 1
749        TLVs in the right order (top-down in Table 3) and nothing else.  A
750        cAdd name is identical to the cState to which it responds.

752         +=======+================+================+=======================+
753         | Level | Level 1        | Level 2        | Comments              |
754         | 0     |                |                |                       |
755         +=======+================+================+=======================+
756         | Type  |                |                | the value 6           |
757         +-------+----------------+----------------+-----------------------+
758         |       | Name           |                | must match Name of    |
759         |       |                |                | cState it's adding to |
760         +-------+----------------+----------------+-----------------------+
761         |       | MetaInfo       |                |                       |
762         +-------+----------------+----------------+-----------------------+
763         |       |                | ContentType    | type cAdd             |
764         +-------+----------------+----------------+-----------------------+
765         |       | Content        |                |                       |
766         +-------+----------------+----------------+-----------------------+
767         |       |                | Publication(s) | one or more           |
768         |       |                |                | Publications to add   |
769         |       |                |                | to the Collection     |
770         +-------+----------------+----------------+-----------------------+
771         |       | SignatureInfo  |                |                       |
772         +-------+----------------+----------------+-----------------------+
773         |       |                | SignatureType  | Value indicates which |
774         |       |                |                | signature manager     |
775         +-------+----------------+----------------+-----------------------+
776         |       |                | KeyLocator     | Presence depends on   |
777         |       |                |                | SignatureType         |
778         +-------+----------------+----------------+-----------------------+
779         |       | SignatureValue |                | Value holds the       |
780         |       |                |                | signature for this    |
781         |       |                |                | PDU                   |
782         +-------+----------------+----------------+-----------------------+

784                                 Table 3: cAdd format

786        The structure of the cState and cAdd Names means that nothing about
787        Publication Names (which are application-oriented) are exposed if
788        encrypted cAdds are specified in a schema.  (The schema itself may be
789        distributed in an encrypted cAdd if desired).

791     2.4.  Interface between application and network interface

793        Figure 7 and Figure 8 show the blocks and modules application
794        information passes through in DeftT.  Its handling of application
795        information can be illustrated using an example of a new Publication
796        at a trust domain member and following its progress into a collection
797        and its reception by other members.  For more detail, see the library
798        at [DCT].  DeftT uses [DCT]'s message-based pub/sub (_mbps_) *shim*
799        which kicks off all the necessary DeftT startup when an mbps object
800        is instantiated by the application.  After startup, the *pub* syncps

nit: whats the difference between your modiles and a shim ?

nit: mbps: easy to confuse with Mbps... recommend different abbreviation.

801        of each member will maintain a cState containing the IBLT of its view
802        of the collection.  (In the stable, synchronized state, all IBLTs are
803        the same.)

805        Applications use an mbps _subscribe_ method to either subscribe to
806        all messages or to a subset by topic, passing a callback function to
807        handle matching items.  These application-level subscriptions are
808        turned into syncps subscriptions via mbps.  When the application has
809        new information to communicate, topic items (as parameters) and
810        message are passed to mbps with a _publish_ call.  Only these topic
811        components and the message, if any, are passed between the
812        application and mbps.  The message may be segmented into multiple
813        Publications by mbps, if the message size exceeds Publication
814        content.  For each Publication, mbps-specific components are added to
815        the parameter list and the services of *schemaLib* are invoked in
816        order to build and publish a valid Publication according to the
817        schema (no Publication will be built if the correct attributes are
818        not contained in the member's identity chain).  The Publication is
819        signed using the _sign_ method of the appropriate *sigmgr* and passed
820        to *syncps*.

822        syncps adds this Publication to its collection and updates its IBLT
823        to contain the new Publication.  Since its application just created
824        it, syncps knows this is a new addition to the collection and it is a
825        response to the current cState.  Thus the Publication is packaged
826        into a cAdd and signed using the _sign_ method of the designated
827        *sigmgr* and passed to the face.  The updated IBLT is packaged into a
828        new cState that is handed to the face.

830        Members of the trust domain specifically respond only to IPv6 cAdds
831        that share their trust domain identifier (Section 2.3.3 and
832        Section 2.3.4).  When a new cAdd is received at a member, the face
833        ensures it matches an outstanding cState and, if so, passes it on to
834        matching syncps(es).  Syncps validates (both structurally and
835        cryptographically) the cAdd using the appropriate sigmgr's _validate_
836        and continues, removing Publications, if valid.  Each Publication is
837        structurally validated via a sigmgr and valid Publications are added
838        to the local collection and IBLT. syncps passes this updated cState
839        to the local face.  If this Publication matches a subscription it is
840        passed to mbps, invoking the sigmgr's decrypt if the Publication is
841        encrypted (Publication decryption is _not_ available at Relays.) mbps
842        receives the Publication and passes any topic components of interest
843        to the application along with the content (if any) to the application

nit: duplicate "to the application" ?

844        via the callback registered when it subscribed.  (If the original
845        content was spread across Publications, mbps will wait until all of
846        the content is received.  The _sCnt_ component of a mbps Publication
847        Name is used for this.)

nit: reference to new sCnt term without reference/explanation.

849     2.5.  Schema-based information movement

851        Although the Internet's transport and routing protocols emphasize
852        universal reachability with packet forwarding based on destination, a
853        significant number of applications neither need nor desire to transit
854        the Internet (e.g., see [RFC8799]).  This is true for a wide class of
855        OT application.  Further, liberal acceptance of packets while
856        depending on the good sending practices of others leaves critical
857        applications open to misconfiguration and attacks.  DeftT *only*
858        moves its Publications in accordance with fully specified
859        communication rules.  This approach differs from Internet forwarding
860        but offers new opportunities to address the specific security
861        requirements of applications in many Limited Domains.

nit: i think this text does not bring home the important point it is trying to
make well:

The notion of destination based datagram (frame/packet) forwarding is the most
widely used mechanism on which communications is built. Ethernet and IP/IPv6
being the most widely used instances. IP/IPv6 specifically are also the enbler
of communications across networking as wide varied s the Internet.

However this communication paradigm is riddled with the security issue of
hacving to transmit and received undesired data which has lead to a whole world
of security mechanisms to protect against it, most memorable firewalls whose
functionality still escapes any useful standardization

As soon as we remove the requirement for a communication paradigm to work
across the Internet, we have a much broader and better set of paradigms that do
not have this issue. In the IETF for example IP Multicast and in the IRTF
ICN/NDN/CCN. Pub/Sub communications a broader set of solutions sharing these
benefits.

something like this...

minor: there is of course however the problem of all these mechanisms of
replacing undesired/authenticated traffic with what in DefT case would probably
have to be called subscription state. It is unclear to me so far how
publications are disributed across varied topologies of relays without flooding
of subscription state to all possible parts of the network. We are doing this
in better multicast protocols (not flooding that state), but that required
pub/sub rendesvous mechanisms which i think i have not seen in the algo
description here. And even when this is done ideally, therer is still the
attack vector of subscription DoS: in any solution where there can be many
topics, you likely expect that only a feasible number is subscribed to, but an
attacker is i think not prevented from subscribing from too many, unless there
is an explicit protection against that in schemata. But then those schemata
would habe to also be enforced in relays because he subscriber in this case is
of course impaired and can't be relied upon.

863        DeftTs on the same subnet may be in different trust domains and
864        DeftTs in the same trust domain may not be on the same subnet.  In
865        some cases, it is useful to define sub-domains whose DeftTs have a
866        compatible, but more limited, version of the trust domain's
867        communications schema.  Compatible means there is at least one
868        publication type and associated signer specification in common or one
869        schema may be a subset of the other.  In the case of sub-domains,
870        they be deployed on the same subnet or on different subnets.  The
871        rules of a sub-domain compiled to a binary schema distributed as a
872        schema cert will have a different thumbprint from that of the full
873        trust domain.

875        In the case of DeftTs on the same subnet but in different trust
876        domains or different sub-domains, the cState and cAdd PDUs of
877        different domains are differentiated by the _domain id_ (thumbprint
878        of the domain's schema certificate as in Table 2) which can be used
879        at the face module to determine whether or not to process a PDU.  A
880        particular sync collection is managed on a single subnet: cState and
881        cAdds are not forwarded off that subnet nor between DeftTs with
882        different domain ids on the same subnet.  Instead, schema-compliant
883        Relays connect Publications between separate sync collections of the
884        same trust domain.  Collections are differentiated by both subnet
885        (the physical media) and domain id (a required field of the cState
886        and cAdd PDUs).  Consequently, cStates and cAdds are subnet-sprecific
887        while Publications belong to a trust domain (or sub-domain).

889        A Relay is implemented [DCT] as an entity running on a device with a
890        DeftT interface on each subnet (two or more) or with multiple DeftT
891        interfaces to the same subnet Figure 9 where each uses a different
892        but compatible version of the others' schema.  Each DeftT
893        participates in different sync collections and uses a communication
894        identity valid for the schema used by the DeftT.  Only Publications
895        (including certs) are relayed between DeftTs and the Publication must
896        validate against the schema of each DeftT.  Consequently cAdd
897        encryption is unique per collection while Publication encryption
898        holds across the domain.

900        As Relays do not originate Publications, their DeftT API module (a
901        "shim", see Section 2.1) performs _pass-through_ of valid
902        Publications.  The Relay of Figure 9-left is on three separate
903        wireless subnets.  If all three DeftTs are using an identical schema,
904        a new validated cert added to the cert store of an incoming DeftT is
905        then passed to the other two, which each validate the cert before
906        adding to their own cert stores (superfluous in this case, but not a
907        lot of overhead for additional security).  When a valid Publication
908        is received at one DeftT, it is passed to the other two DeftTs to
909        validate against their schemas and published if it passes.

911        (Artwork only available as svg: figs/relayextend-rfc.svg)

913                           Figure 9: Relays connect subnets

915        A Relay may have different identities and schemas for each DeftT but
916        _must_ have the same trust anchor and schemas must be identical
917        copies, proper subsets or overlapping subsets of the domain schema.
918        Publications that are undefined for a particular DeftT will be
919        silently discarded when they do not validate upon relay, just as they
920        are when received from a face.  This means the Relay application of
921        Figure 9-left can remain the same but Publications will only be
922        published to a different subnet if its DeftT has that specification
923        in its schema.  Relays may filter Publications at the application
924        level or restrict subscriptions on some of their DeftT interfaces.
925        Figure 9-right shows extending a trust domain geographically by using
926        a unicast connection (e.g., over a cell line or tunnel over the
927        Internet) between two Relays which also interface to local broadcast
928        subnets.  Everything on each local subnet shows up on the other.  A
929        communications schema subset could be used here to limit the types of
930        Publications sent on the remote link, e.g., logs or alerts.  Using
931        this approach in Figure 9-right, local communications for subnet 1
932        can be kept local while subnet 2 might send commands and/or collect
933        log files from subnet 1.

minor: this sounds like per-subnet schema defintion based propagation policies
instead of automatically driven by subscriptions. That would be a quite big
amount of administrative work and potential for misconfiguration. It likely
does fit the command&control desire of todays very static OT network management
approaches, but i am not sure it would suit more dynamic type of deployment
(agile manufacturing for example).

But i may be wrong in interpreting this. The explanations are quite dense
without examples.

935        More generally, Relays can form a mesh of broadcast subnets with no
936        additional configuration (i.e., Relays on a broadcast network do not
937        need to be configured with others' identities and can join at any
938        time).  The mesh is efficient: publications are only added to an
939        individual DeftT's collection once regardless of how it is received.
940        Relays with overlapping broadcast physical media will only add a
941        Publication to any of its DeftTs *once*; syncps ensures there are no
942        duplicates.  More on the applicability of DeftT meshes is in
943        Section 5.

945     2.6.  Congestion control

947        Each DeftT manages its collection on a single broadcast subnet (since
948        unicast is a proper subset of multicast, a point-to-point connection
949        is viewed as a trivial broadcast subnet) thus only has to deal with
950        that subnet's congestion.  As described in the previous section, a
951        device connected to two or more subnets may create DeftTs having the
952        same collection name on each subnet with a *Publication* Relay
953        between them but DeftT never forwards *PDUs* between subnets.  It is,
954        of course, possible to run DeftT over an extended broadcast network
955        like a PIM multicast group but the result will generally require more
956        configuration and be less reliable, efficient and secure than DeftT's
957        self-configuring peer-to-peer Relay mesh.

959        DeftT sends _at most one_ copy of any Publication over any subnet,
960        _independent_ of the number of publishers and subscribers on the
961        subnet.  Thus the total DeftT traffic on a subnet is strictly upper

nit: again ignoring the message loss case - whicha actually is covered ?!

962        bounded by the application-level publication rate.  As described in
963        Section 2.2, DeftTs publish a cState specifying the set elements they
964        currently hold.  If a DeftT receives a cState specifying the same
965        elements (Publications) it holds, it doesn't send its cState.  Thus
966        the upper bound on cState publication rate is the number of members
967        on the subnet divided by the cState lifetime (typically seconds to
968        minutes) but is typically one per cState lifetime due to the
969        duplicate suppression.  Each member can send at most one cAdd in
970        response to a cState.  This creates a strict request/response flow
971        balance which upper bounds the cAdd traffic rate to (number of
972        members - 1) times the cState publication rate.  The flow balance
973        ensures an instance can't send a new cState until it's previous one
974        is either obsoleted by a cAdd or times out.  Similarly a cAdd can
975        only be sent in response to the cState which it obsoletes.  Thus the
976        number of outstanding PDUs per instance is at most one and DeftT
977        cannot cause subnet congestion collapse.

979        If a Relay is used to extend a trust domain over a path whose
980        bandwidth delay product is many times larger than typical subnet MTUs
981        (1.5-9KB), the one-outstanding-PDU per member constraint can result
982        in poor performance (1500 bytes per 100ms transcontinental RTT is
983        only 120Kbps).  DeftT can run over any lower layer transport and
984        stream-oriented transports like TCP or QUIC allow for a 'virtual MTU'
985        that can be set large enough for DeftT to relay at or above the
986        average publication rate (the default is 64KB which can relay up to
987        5Mbps of publications into a 100ms RTT).  In this case there can be
988        many lower layer packets in flight for each DeftT cAdd PDU but their
989        congestion control is handled by TCP or QUIC.

991     3.  Defined-trust management engine

993        OT applications are distinguished (from general digital
994        communications) by well-defined roles, behaviors and relationships
995        that constrain the information to be communicated (e.g., as noted in
996        [RFC8520]).  Structured abstract profiles characterize the
997        capabilities and attributes of Things and can be machine-readable
998        (e.g., [ONE][RFC8520][ZCL]).  Energy applications in particular have
999        defined strict role-based access controls [IEC] though proposed
1000       enforcement approaches require interaction of a number of mechanisms
1001       across the communications stack [NERC].  Structured profiles and

nit: rephrase sentence, hard to read.

1002       rules strictly define permitted behaviors including what types of
1003       messages can be issued or acted on; undefined behaviors are not
1004       permitted.  These rules, along with local configuration, are
1005       incorporated directly into the schemas used by DeftT's integrated
1006       trust management engine to both prohibit undefined behaviors and to
1007       construct compliant Publications.  This not only provides a fine-
1008       grained security but a highly _usable_ security, an approach that can
1009       make an application writer's job easier since applications do not
1010       need to contain local configuration and security considerations.

1012       DCT [DCT] includes a language for expressing the rules of
1013       communication, its compiler, and other tools to create the
1014       credentials a DeftT needs at run-time.  DCT is example code, not
1015       currently optimized for performance.

nit: seems a bit of a contradiction with line 521/522 (not optimzied for
performance).

1017    3.1.  Communications schemas

1019       Defined-trust's use of communications schemas has been influenced by
1020       [SNC][SDSI] and the field of _trust management_ defined by Blaze et.
1021       al.  [DTM] as the study of security policies, security credentials,
1022       and trust relationships.  Li et. al.  [DLOG] refined some trust
1023       management concepts arguing that the expressive language for the
1024       rules should be _declarative_ (as opposed to the original work).
1025       Communications schemas also have roots in the _trust schemas_ for
1026       Named-Data Networking, described by Yu et al [STNDN] as "an overall
1027       trust model of an application, i.e., what is (are) legitimate key(s)
1028       for each data packet that the application produces or consumes."
1029       [STNDN] gave a general description of how trust schema rules might be
1030       used by an authenticating interpreter finite state machine to
1031       validate packets.  A new approach to both a trust schema language and
1032       its integration with communications was introduced in [NDNW] and
1033       extended in [DNMP][IOTK][DCT].  In this approach, a schema is
1034       analogous to the plans for constructing a building.  Construction
1035       plans serve multiple purposes:

1037       1.  Allow permitting authorities to check that the design meets
1038           applicable codes
1039       2.  Show construction workers what to build
1040       3.  Let building inspectors validate that as-permitted matches as-
1041           built

1043       Construction plans get this flexibility from being declarative: they
1044       describe "what", not "how".  As noted in p4 of [DLOG], a declarative

nit: use of non-explained term p4. I guess its the Barefoot programmable
mnetwork switch programming language ? ;-)) oh.. page 4 ? No..

1045       trust management specification based on a formal foundation
1046       guarantees all parties to a communication have the same notion of
1047       what constitutes compliance.  This allows a single schema to provide
1048       the same protection as dozens of manually configured, per-node ACL
1049       rules.  This approach is a critical part of Defined-trust
1050       Communications which uses the more descriptive term _communication
1051       schema_ as the rules define the communications of a trust domain.

minor: If i use my DFeft scheme with a lot of automation, i am going to be
better han if you use your ACL only with manual configuration and without
tools. A fairer comparison of course is how they would compare if you assumed
the samer type of complex, automatated/validated management engine for ACLs as
for DefT. And i think there are a couple of those in use in networks. One could
consider MUD to be a stepping stone to that, but there has through 30++ years
of using ACLs in TCP/IP networks a lot of tools developed. Role Based access
control has long since been used in enterprise networks. IMHO give or take tht
is usually hasn't been tied to cryptographic identities or pub/sub (might
exist, i am just not aware of it), it's fundamentally the same. So maybe fairer
to acknowledge the history of starting with management systems for ACLs and
then evolving into doing the same for pub/sub and using message based
cryptographic end-to-end security - to get the right mix (DefT).

But in general, every communication paradigm can be enhanced when you assume
a component by which you specify "who can do what"and then create automation
from that spe ification to support various goals from that knowlede - security,
efficiency, etc... But it does introduce a whole new design paradigm which does
not lend itself well to real distributed systems where communicating components
are not under a single authority. The controlled networks / limited domains we
did talk about in the IETF so far where only expecting this type of
coordination up to some point in the stack. This DefT approach takes it a much
higher/stronger layer. It perfectly fits a lot of traditional OT. But one
should be careful to assume applicability to a wider range of scenarious
without reviewing the operational details that would have to emerge. How about
when components of an application are independently developed ? Who holds
authority of definition of schematas ?

1053       VerSec, an approach to creating schemas, is included with the
1054       Defined-trust Communications Toolkit [DCT].  VerSec includes a
1055       declarative schema specification language with a compiler that checks
1056       the formal soundness of a specification (case 1 above) then converts
1057       it to a signed, compact, binary form.  The diagnostic output of the
1058       compiler (including a digraph listing) can be used to inspect that
1059       the intent for the communications schema has indeed been implemented.
1060       The binary form is used by DeftT to build (case 2) or validate (case
1061       3) the Publications (format covered in Section 2.3.1).  Certificates
1062       (Section 2.3.2) are a type of Publication, allowing them to be
1063       distributed and validated using DeftT, but they are subject to many
1064       additional constraints that ensure DeftT's security framework is
1065       well-founded.

1067    3.2.  A schema language

1069       The VerSec language follows LangSec [LANG] principles to minimize
1070       misconfiguration and attack surface.  Its structure is amenable to a
1071       forms-based input or a translator from the structured data profiles
1072       often used by standards [ONE][RFC8520][ZCL].  Declarative languages
1073       are expressive and strongly typed, so they can express the constructs
1074       of these standards in their rules.  VerSec continues to evolve and
1075       add new features as its application domain is expanded; the latest
1076       released version is at [DCT].  Other languages and compilers are
1077       possible as long as they supply the features and output needed for
1078       DeftT.

1080       A communication schema expresses the intent for a domain's
1081       communications in fine-grained rules: "who can say what."
1082       Credentials that define "who" are specified along with complete
1083       definitions of "what".  Defined-trust communications has been
1084       targeted at OT networking where administrative control is explicit
1085       and it is not unreasonable to assume that identities and
1086       communication rules can be securely configured at every device.  The
1087       schema details the meaning and relationship of individual components
1088       of the filename-like names (URI syntax [RFC3986]) of Publications and
1089       certificates.  A simple communications schema (Figure 10) defines a
1090       Publication in this domain as *#pub* with a six component name.  The
1091       strings between the slashes are the tags used to reference each
1092       component in the structured format and in the run-time schema
1093       library.  An example of this usage is the component constraint
1094       following the "&" where _ts_ is a timestamp (64-bit unix timepoints
1095       in microseconds) which will be set with the current time when a
1096       Publication is created.  The first component gets its value from the
1097       variable "domain" and #pubPrefix is designated as having this value
1098       so that the schema contains information on what part of the name is
1099       considered common prefix.  For the sake of simplicity, the Figure 10
1100       schema puts no constraints on other name components (not the usual
1101       case for OT applications) but requires that Publications of template
1102       #pub are signed by ("<=") a *mbrCert* whose format and signing rule
1103       (signed by a netCert) is also defined.  The Validator lines specify
1104       cryptographic signing and validation algorithms from DCT's run-time
1105       library for both the Publication and the cAdd PDU that carries
1106       Publications.  Here, both use EdDSA signing.  This schema has no
1107       constraints on the inner four name components (additional constraints
1108       could be imposed by the application but they won't be enforced by
1109       DeftT).  Member identity comes from a *mbrCert* which allows it to
1110       create legal communications (using the associated private key in
1111       signing).  A signing certificate must adhere to the schema;
1112       Publications or cAdds with unknown signers are discarded.  The
1113       timestamp component is used to prevent replay attacks.  A DeftT adds
1114       its identity certificate chain to the domain certificate collection
1115       (see Section 4.2) at its startup, thus announcing its identity to all
1116       other members.  Using the pre-configured trust anchor and schema, any
1117       member can verify the identity of any other member.  This approach
1118       means members are not pre-configured with identities of other members
1119       of a trust domain and new entities can join at any time.

nit: And the clear winner of longest paragraph is here! ;-)

1121     #pub: /_domain/trgt/topic/loc/arg/_ts & { _ts: timestamp() } <= mbrCert
1122     mbrCert:       _domain/_mbrType/_mbrId/_keyinfo <= netCert
1123     netCert:        _domain/_keyinfo
1124     #pubPrefix:     _domain
1125     #pubValidator:  "EdDSA"
1126     #cAddValidator: "EdDSA"
1127     _domain:        "example"
1128     _keyinfo:       "KEY"/_/"dct"/_

1130                  Figure 10: An example communication schema

nit: what (pseudo) language is this ? please write somewhere (In tag ?)

1132       To keep the communications schema both compact and secure, it is
1133       compiled into a binary format that becomes the content of a schema
1134       certificate.  The [DCT] _schemaCompile_ converts the text version
1135       (e.g.  Figure 10) of the schema into binary as well as reporting
1136       diagnostics (see Figure 11) used to confirm the intent of the rules
1137       (and to flag problems).

1139       Publication #pub:
1140         parameters: trgt topic loc arg
1141         tags: /_domain/trgt/topic/loc/arg/_ts
1142       Publication #pubPrefix:
1143         parameters:
1144         tags: /_domain
1145       Publication #pubValidator:
1146         parameters:
1147         tags: /"EdDSA"
1148       Publication #cAddValidator:
1149         parameters:
1150         tags: /"EdDSA"
1151       Certificate templates:
1152         cert mbrCert: /"example"/_mbrType/_mbrIdId/"KEY"/_/"dct"/_
1153         cert netCert: /"example"/"KEY"/_/"dct"/_
1154       binary schema is 301 bytes

1156        Figure 11: schemaCompile diagnostic output for example of Figure 10

1158       Even this simple schema provides useful security, using enrolled
1159       identities both to constrain communications actions (via its #*pub*
1160       format) and to convey membership.  To increase security, more detail
1161       can be added to Figure 10.  For example, different types of members
1162       can be created, e.g., "admin" and "sensor", and communications
1163       privacy can added by specifying AEAD Validator to encrypt cAdds or
1164       AEADSGN (signed AEAD) to encrypt Publications.  To make those member
1165       types meaningful, a role-based security policy could be employed by
1166       defining Publications such that only admins can issue _commands_ and
1167       only sensors can issue _status_. Specifying the AEAD validator for
1168       the cAddValidator means that at least one member of a subnet will
1169       need a key maker attribute in its signing chain.  If AEADSGN is
1170       specified for the pubValidator, at least one member of the trust
1171       domain will need key maker capability.  In Figure 11 key maker
1172       capability is added to the signing chain of all sensors.  WIth AEAD
1173       specified, a key maker is elected during DeftT start up and that key
1174       maker creates, publishes, and periodically updates the shared
1175       encryption key.  (Late joining entities are able to discover that a
1176       key maker has already been chosen.)  These are the _only_ changes
1177       required in order to increase security and add privacy: neither code
1178       nor binary needs to change and DeftT handles all aspects of
1179       validators.  The unique approach to integrating communication rules
1180       into the transport makes it easy to produce secure application code.

1182       adminCert:  mbrCert & { _mbrType: "admin" } <= netCert
1183       sensorCert: mbrCert & { _mbrType: "sensor" } <= kmCap
1184       capCert:    _network/"CAP"/_capId/_capArg/_keyinfo <= netCert
1185       kmCap:      capCert & { _capId: "KM" }
1186       #reportPub: #pub & {topic:"status"} <= sensorCert
1187       #commandPub: #pub & {topic:"command"} <= adminCert
1188       #cAddValidator: "EdDSA"

1190                Figure 12: Enhancing security in the example schema

1192       In DeftT, identities include the member cert and its entire signing
1193       chain.  By adding attributes via _capability certificates_ in a
1194       member cert's signing chain, attribute-based security policies can be
1195       implemented without the need for separate servers accessed at run-
1196       time (and the attendant security weaknesses).  More on certs will be
1197       covered in Section 4.

1199       Converting desired behavioral structure into a schema is the major
1200       task of applying Defined-trust Communications to an application
1201       domain.  Once completed, all the deployment information is contained
1202       in the schema.  Although a particular schema cert defines a
1203       particular trust domain, the text version of a schema can be re-used
1204       for related applications.  For example, a home IoT schema could be
1205       edited to be specific to a particular home network or a solar rooftop
1206       neighborhood and then signed with a chosen trust anchor.

1208    4.  Certificates and identity bundles

1210       Defined-trust's approach is partially based on the seminal SDSI
1211       [SDSI] approach to create user-friendly namespaces that establish
1212       transitive trust through a certificate (cert) chain that validates
1213       locally controlled and managed keys, rather than requiring a global
1214       Public Key Infrastructure (PKI).  When certificates are created, they

nit: Most PKI are local. As said before, it more proper to refer to WebPKI as
the global PKI you are trying to distinguish yourself against.

1215       have a particular context in which they should be utilized and
1216       trusted rather than conferring total authority.  This is particularly
1217       useful in OT where communicating entities share an administrative
1218       control and using a third party to certify identity is both
1219       unnecessary and a potential security vulnerability.  Well-formed
1220       certificates and identity deployment are critical elements of this
1221       framework.  This section describes certificate requirements and the
1222       identity _bundles_ that are securely distributed to trust domain
1223       members.  (DCT includes utilities to create certs and bundles.)

1225    4.1.  Obviate CA usage

1227       Use of third party certificate authorities (CAs) is often
1228       antithetical to OT security needs.  Any use of a CA (remote or local)
1229       results in a single point of failure that greatly reduces system
1230       reliability.  An architecture with a single, local, trust root cert
1231       (trust anchor) and no CAs simplifies trust management and avoids the
1232       well-known CA federation and delegation issues and other weaknesses
1233       of the X.509 architecture (summarized at [W509], original references
1234       include [RSK][NVR]).  DCT certificates (see Section 2.3.2) can be
1235       generated and signed locally (using supplied utilities) so there is
1236       no reason to aggregate a plethora of unrelated claims into one cert
1237       (avoiding the Aggregation problem [W509]).

nit: again, i am not an expert here, and you may want to ask for LAMPs review,
but i would refer to WebPKI RFC5280 as opposed to X.509, because X.509 has
nothing to do wih the Internet, WebPKI. For example all IDevID in devices are
X.509 certificates and typically are based on complete local trust anchors of
manufacturers that donot need to be tied into any WebPKI (some may or may not
be).

1239       A DCT cert's one and only Subject Name is the Name of the Publication
1240       that contains the public key as its content and neither name nor
1241       content are allowed to contain any optional information or
1242       extensions.  Certificates are created with a lifetime; local
1243       production means cert lifetimes can be just as long as necessary (as
1244       recommended in [RFC2693]) so there's no need for the code burden and
1245       increased attack surface associated with certificate revocation lists
1246       (CRLs) or use of on-line certificate status protocol (OSCP).  Keys
1247       that require longer lifetimes, like device keys, get new certs before
1248       the current ones expire and may be distributed through DeftT (e.g.,
1249       using a variant of the group key distributors in DCT).  If there is a
1250       need to exclude previously authorized identities from a domain, there
1251       are a variety of options.  The most expedient is via use of an AEAD
1252       cAdd or Publication validator by ensuring that the group key maker(s)
1253       of a domain exclude that entity from subsequent symmetric key
1254       distributions until its identity cert expires (and it is not issued
1255       an update).  Another option is to publish an identity that supplants
1256       that of the excluded member.  Though more complex, it is also
1257       possible to distribute a new schema and identities (without changing
1258       the trust anchor), e.g., using remote attestation via the TPM.

nit: you're reinventing OCSP with your cAdd, aren't you ? Which is fine, given
how you can pub that inforrmation - but it would be less confusing if you said
so.

1260       From Section 3, a member cert is granted attributes in the schema via
1261       the certs that appear in its member identity chain.  Member certs are
1262       _always_ accompanied by their full chain-of-trust, both when
1263       installed and when the member publishes its identity to the cert
1264       collection.  Every signing chain in the domain has the same trust
1265       anchor at its root and its legal form specified in the schema.
1266       Without the entire chain, a signer's right to issue Publications
1267       cannot be validated.  Cert validation is according to the schema
1268       which may specify attributes and capabilities for Publication signing
1269       from any certificate in the chain.  For this model to be well
1270       founded, each cert's *key locator* must _uniquely_ identify the cert
1271       that actually signed it.  This property ensures that each locator
1272       resolves to one and only one signing chain.  A cert's key locator is
1273       a *thumbprint*, a SHA256 hash of the _entire_ signer's Publication
1274       (name, content, key locator, and signature), ensuring that each
1275       locator resolves to one and only one cert and signing chain.  Use of
1276       the thumbprint locator ensures that certs are not open to the
1277       substitution attacks of name-based locators like X.509's "Authority
1278       Key Identifier" and "Issuer" [ConfusedDep][CAvuln][TLSvuln].

1280    4.2.  Identity bundles

1282       Identity bundles comprise the certificates needed to participate in a
1283       trust domain: trust anchor, schema, and the member's identity chain.
1284       The private key corresponding to the leaf certificate of the member's
1285       identity chain should be installed securely when a device is first
1286       commissioned (e.g., out-of-band) for a network.  The public certs of
1287       the bundle may be placed in a file in a well-known location or may,
1288       in addition, have their integrity attested or even be encrypted.
1289       Secure device configuration and on-boarding should be carried out
1290       using the best practices most applicable to a particular deployment.
1291       The process of enrolling a device by provisioning an initial secret
1292       and identity in the form of public-private key pair and using this
1293       information to securely onboard a device to a network has a long
1294       history.  Current and emergent industry best practices provide a
1295       range of approaches for both secure installation and update of
1296       private keys.  For example, the private key of the bundle can be
1297       secured using the Trusted Platform Module, the best current practice
1298       in IoT [TATT][DMR][IAWS][TPM][OTPM][SIOT][QTPM][SKH][RFC8995], or
1299       secure enclave or trusted execution environment (TEE) [ATZ].  In that
1300       case, an authorized configurer adding a new device can use TPM tools
1301       to secure the private signing key and install the rest of the bundle
1302       file in a known location before deploying the device in the network.
1303       Where entities have public-private key pair identities of _any_
1304       (e.g., non-DCT) type, these can be leveraged for DeftT identity
1305       installation.  Figure 13 shows the steps involved in configuring
1306       entities and their correspondence of the steps to the "building
1307       plans" model.  (The corresponding tools available in DCT are shown
1308       across the bottom and the relationship to the "building plans" model
1309       is shown across the top.)

1311       (Artwork only available as svg: figs/tools.config-rfc.svg)
1312                Figure 13: Creating and configuring identity bundles

1314       In the examples at [DCT], an identity bundle is given directly to an
1315       application via the command line, useful for development, and the
1316       application passes callbacks to utility functions that supply the
1317       certs and a signing pair separately.  For deployment, good key
1318       hygiene using best current practices must be followed e.g., [COMIS].
1319       In deployment, a small application manager may be programmed for two
1320       specific purposes.  First, it is registered with a supervisor [SPRV]
1321       (or similar process control) for its own (re)start to serve as a
1322       bootstrap for the application.  Second, it can have access to the TPM
1323       functions and the ability to create "short-lived" (~hours to several
1324       days) public/private key pair(s) that are signed by the installed
1325       (commissioned) private identity key using the TPM.  This publication
1326       signing key pair is created at (re)start and at the periodicity of
1327       the signing cert lifetime.  Since the signing happens via requests to
1328       the TPM, the identity key cannot be exfiltrated.

1330       The DCT examples and library use member identities to create signing
1331       certs (with associated secret keys) and the example schemas give the
1332       format for these signing cert names.  A DeftT will request a new
1333       signing cert shortly before expiration of the one in use.

1335       Upon each signing cert update, only the new cert needs to be
1336       published via DeftT's cert distributor.  Figure 14 outlines a
1337       representative procedure.

1339       (Artwork only available as svg: figs/InstallIdbundle-rfc.svg)

1341        Figure 14: Representative commissioning and signing key maintenance

1343       All DCT certs have a validity period.  Certs that sign publications
1344       are generated locally so they can easily be refreshed as needed.
1345       Trust anchors, schemas, and the member identity chain are higher
1346       value and often require generation under hermetic conditions by some
1347       authority central to the organization.  Their lifetime should be
1348       application- and deployment-specific, but the higher difficulty of
1349       cert production and distribution often necessitates liftetimes of
1350       weeks to years.

1352       Updating schemas and other certificates over the deployed network
1353       (OTA) is application-domain specific and can either make use of
1354       domain best practices or develop custom DeftT-based distribution.
1355       Changing the trust anchor is considered a re-commissioning.  The
1356       example here is merely illustrative; with pre-established secure
1357       identities and well-founded approaches to secure on-line
1358       communications, a trust domain could be created OTA using secure
1359       identities established through some other system of identity.

1361    5.  Use Cases

1363    5.1.  Secure Industrial IoT

1365       IIoT sensors offer significant advantages in industrial process
1366       control including improved accuracy, process optimization, predictive
1367       maintenance and analysis, higher efficiency, low-cost remote
1368       accessibility and monitoring, reduced downtime, power savings, and
1369       reduced costs [IIOT].  The large physical scale of many industrial
1370       processes necessitates that expensive cabling costs be avoided
1371       through wireless transport and battery power.  This is a particular
1372       issue in nuclear power plant applications where radioactive shielding
1373       walls are very thick concrete and security regulations make any plant
1374       modifications to add cabling subject to expensive and time-consuming
1375       reviews and permitting.  Wireless sensor deployments in an industrial
1376       environment can suffer from signal outages due to shielding walls and
1377       interference caused by rotating machinery and electrical generators.
1378       Multiple _gateway_ devices can receive sensor information and
1379       transmit it to monitor/controllers and servers.  These gateway
1380       devices can run DeftT Relay applications and be deployed in a robust
1381       wireless mesh that is resilient against transmission outages,
1382       facilitating reliability.  DeftT forms meshes with no additional
1383       configuration (beyond DeftT's usual identity bundle and private key)
1384       as Publications are sent once and heard by all in-range members while
1385       Publications missing from one DeftT's set can be supplied by another
1386       within range.  Several gateways may typically be within a single
1387       sensor's wireless range, reducing the number of lost sensor packets.
1388       Other meshed gateways can relay the sensor's Publications either
1389       wirelessly or via a wired ethernet backhaul.

1391       IIoT sensors require tight security.  Critical Digital Assets (CDA)
1392       are a class of industrial assets such as power plants or chemical
1393       factories which must be carefully controlled to avoid loss-of-life
1394       accidents.  Even when IIoT sensors are not used for direct control of
1395       CDA, spoofed sensor readings can lead to destructive behavior.  There
1396       are real-life examples (such as uranium centrifuges) of nation-state
1397       actors changing sensor readings through cyberattacks leading to
1398       equipment damage.  These risks result in a requirement for stringent
1399       security reviews and regulation of CDA sensor networks.  Despite the
1400       advantages of deploying CDA sensors, adequate security is
1401       prerequisite to deploying the CDA sensors.  Information conveyed via
1402       DeftT has an ensured provenance and may be encrypted in an efficient
1403       implementation making it ideal for this use.

1405       IIoT sensors may be mobile (including drone-based) and different
1406       gateways may receive packets from a particular sensor over time.  A
1407       DeftT mesh captures Publications _anywhere_ within its combined
1408       network coverage area and ensures it efficiently reaches all members
1409       as long as they are in range of at least one member that has received
1410       the information.  An out-of-service or out-of-range member can
1411       receive all active subscribed publications once it is in range and/or
1412       able to communicate.  This use of DeftT is illustrated in Figure 15
1413       where bluetooth-using devices (BT Dev) are deployed as sensors,
1414       switches, cameras, lock openers, etc.  A WiFi network includes tablet
1415       devices and a monitor/controller computer.  Gateway devices each have
1416       a Relay using both a Bluetooth interface and a WiFi interface.
1417       Gateways are placed so that there is always at least one in range of
1418       a BT device and at least one other Gateway (or the Controller) in its
1419       WiFi range.  WiFi tablets can move around within range of one or more
1420       Gateways.  All the DeftTs may use the same schema, giving devices on
1421       the WiFi network access to all of the BT devices.  Applications on
1422       any particular device may subscribe to a subset of the information
1423       available.  If privacy of longer-range data is required, the WiFi
1424       DeftTs can use a schema that requires encrypting its cAdds.  These
1425       configuration choices are made by changes in the schemas alone, the
1426       application code is exactly the same.  No configuration is needed to
1427       make devices recognize one another and syncps will keep
1428       communications efficient, ensuring that all DeftTs in the trust
1429       domain know what information is available.  The face ensures that
1430       identical cStates are only sent once (within broadcast range).  These
1431       features mean that DeftT forms efficient broadcast meshes with no
1432       additional configuration beyond identity bundles, an important
1433       advantage.

1435       (Artwork only available as svg: figs/meshEx-rfc.svg)

1437           Figure 15: IIOT meshed gateways connect a single trust domain

1439       In addition to specifying encryption and signing types, schema rules
1440       control which users can access specific sensors.  For example, an
1441       outside predictive maintenance analysis vendor can be allowed access
1442       to the vibration sensor data from critical motors, relayed through
1443       the Internet, while only plant Security can see images from on-site
1444       cameras.

1446    5.2.  Secure access to Distributed Energy Resources (DER)

1448       The electrical power grid is evolving to encompass many smaller
1449       generators with complex interconnections.  Renewable energy systems
1450       such as smaller-scale wind and solar generator sites must be
1451       economically accessed by multiple users such as building owners,
1452       renewable asset aggregators, utilities, and maintenance personnel
1453       with varying levels of access rights.  North American Electric
1454       Reliability Corporation Critical Infrastructure Protection (NERC CIP)
1455       regulations specify requirements for communications security and
1456       reliability to guard against grid outages [DER].  Legacy NERC CIP
1457       compliant utility communications approaches, using dedicated
1458       physically secured links to a few large generators, are no longer
1459       practical.  DeftT offers multiple advantages over bilateral TLS
1460       sessions for this use case:

1462       *  Security.  Encryption, authentication, and authorization of all
1463          information objects.  Secure brokerless pub/sub avoids single-
1464          point broker vulnerabilities.  Large generation assets of hundreds
1465          of megawatts to more than 1 gigawatt, particularly nuclear power
1466          plants must be controlled securely or risk large-scale loss of
1467          life accidents.  Hence, they are attractive targets for
1468          sophisticated nation-state cyber attackers seeking damage with
1469          national security implications.  Even small-scale DER generators
1470          are susceptible to a coordinated attack which could still bring
1471          down the electric grid.
1472       *  Scalability.  Provisioning, maintaining, and distributing multiple
1473          keys with descriptive, institutionalized, hierarchical names.
1474          DeftT allows keys to be published and securely updated on-line.
1475          Where historically a few hundred large-scale generators could
1476          supply all of the energy needs for a wide geographic area, now
1477          small-scale DER such as residential solar photovoltaic (PV)
1478          systems are located at hundreds of thousands of geographically
1479          dispersed sites.  Many new systems are added daily and must be
1480          accommodated economically to spur wider adoption.
1481       *  Resiliency.  A mesh network of multiple client users, redundant
1482          servers, and end devices adds reliability without sacrificing
1483          security.  Generation assets must be kept on-line continuously or
1484          failures risk causing a grid-wide blackout.  Climate change is
1485          driving frequent natural disasters including wildfires,
1486          hurricanes, and temperature extremes which can impact the
1487          communications infrastructure.  If the network is not resilient
1488          communications breakdowns can disable generators on the grid
1489          leading to blackouts.
1490       *  Efficiency.  Data can be published once from edge gateways over
1491          expensive cellular links and be accessed through servers by
1492          multiple authorized users, without sacrificing security.  For
1493          small residential DER systems, economical but reliable
1494          connectivity is required to spur adoption of PV compared to
1495          purchasing from the grid.  However, for analytics, maintenance and
1496          grid control purposes, regular updates from the site by multiple
1497          users are required.  Pub/sub via DeftT allows both goals to be met
1498          efficiently.
1499       *  Flexible Trust rules: Varying levels of permissions are possible
1500          on a user-by-user and site-by-site basis to tightly control user
1501          security and privacy at the information object level.  In an
1502          energy ecosystem with many DER, access requirements are quite
1503          complex.  For example, a PV and battery storage system can be
1504          monitored on a regular basis by a homeowner.  Separate equipment
1505          vendors for batteries and solar generation assets, including
1506          inverters, need to perform firmware updates or to monitor that the
1507          equipment is operating correctly for maintenance and warranty
1508          purposes.  DER aggregators may contract with a utility to supply
1509          and control multiple DER systems, while the utility may want to
1510          access production data and perform some controls themselves such
1511          as during a fire event where the system must be shut down.
1512          Different permissions are required for each user.  For example,
1513          hourly usage data which gives detailed insight into customer
1514          behaviors can be seen by the homeowner, but for privacy reasons
1515          might only be shared with the aggregator if permission is given.
1516          These roles and permissions can be expressed in the communication
1517          rules and then secured by DeftT's use of compiled schemas.

1519       The specificity of the requirements of NERC CIP can be used to create
1520       communication schemas that contain site-specifics, allowing
1521       applications to be streamlined and generic for their functionality,
1522       rather than containing security and site-specifics.

1524    6.  Using Defined-trust Communications without DeftT

1526       Parts of the defined-trust communications framework could be used
1527       without the DeftT protocol.  There are two main elements used in

nit: Why ? What benefit would that have ? Incremental deployment ? Pl.s explain.

1528       DeftT: the integrated trust management engine and the multi-party
1529       communications networking layer that makes use of the properties of a
1530       broadcast medium.  It's possible to make use of either of these
1531       without DeftT.  For example, a message broker could implement the
1532       trust management engine on messages as they arrive at the broker
1533       (e.g., via TLS) to ensure the sender has the proper identity to
1534       publish such a message.  If a credential is required in order to
1535       subscribe to certain messages, that could also be checked.  Set
1536       reconciliation could be used at the heart of a transport protocol
1537       without using defined-trust security, though signing, encryption, or
1538       integrity hashing could still be employed.

1540    7.  Terms

nit: Move upfront in the document. Usual place where we have this in IETF RFCs.
(AFAIK)

1542       *  certificate thumbprint: the 32 byte SHA256 digest of an _entire_
1543          certificate including its signature ensuring that each thumbprint
1544          resolves to one and only one cert and signing chain
1545       *  collection: a set of elements denoted by a structured name that
1546          includes the identifier of a particular communications schema
1547       *  communications schema: defined set of rules that cover the
1548          communications for a particular application domain.  Where it is
1549          necessary to distinguish between the human readable version and
1550          the compiled binary version, the modifiers "text" or "binary" will
1551          be used.  The binary version is placed in a certificate signed by
1552          the domain trust anchor.

1554       *  DCT: Defined-trust Communications Toolkit.  Running code, examples
1555          and documentation for defined-trust communications tools, a schema
1556          language and compiler, a DeftT implementation, and illustrative
1557          examples
1558       *  face: maintains tables of DeftT's cState PDUs to manage efficient
1559          communications with the system transport in use (UDP multicast,
1560          TCP, etc.)
1561       *  identity: a certificate signing chain with a particular domain's
1562          trust anchor at its root and a unique member certificate as the
1563          leaf.  The public certificates in the chain contain attributes and
1564          capabilities for the leaf member cert.  The secret key associated
1565          with the public key of the member cert should be securely
1566          configured for member use.
1567       *  identity bundle - entities in a trust domain are commissioned with
1568          an identity bundle of trust anchor, signed communication schema
1569          cert, and the signing chain associated with a particular identity
1570       *  Publication: a named information object exchanged used by DeftT
1571          where name structure and the required identity roles and
1572          capabilities for Publications are specified by the schema.
1573          Publications are the elements of the sets that are reconciled by
1574          DeftT's sync protocol.  (Capitalization is used to distinguish
1575          this specific use from both the action and more generic use of the
1576          term.)
1577       *  protocol data unit (PDU): a single unit of information transmitted
1578          among entities of a network composed of protocol-specific control
1579          information and user data.  DeftT uses two types: cState: (from
1580          "collection state") and cAdd: (from "collection additions")
1581       *  sync protocol: a synchronization protocol that implements set
1582          reconciliation of Publications on a subnet making use of cState
1583          and cAdd PDUs
1584       *  Things: as per [RFC8520], networked digital devices specifically
1585          not intended to be used for general purpose computing
1586       *  trust anchor: NIST SP 800-57 Part 1 Rev. 5 definition "An
1587          authoritative entity for which trust is assumed.  In a PKI, a
1588          trust anchor is a certification authority, which is represented by
1589          a certificate that is used to verify the signature on a
1590          certificate issued by that trust-anchor.  The security of the
1591          validation process depends upon the authenticity and integrity of
1592          the trust anchor's certificate.  Trust anchor certificates are
1593          often distributed as self-signed certificates."  In defined-trust
1594          communications, a trust anchor is a self-signed certificate which
1595          is the ultimate signer of all certificates in use in a trust
1596          domain, including the communications schema.  From RFC4949: trust
1597          anchor definition: An established point of trust (usually based on
1598          the authority of some person, office, or organization) which
1599          allows the validation of a certification chain.

1601       *  trust domain: a shorthand form for _Defined-trust Communications
1602          Limited Domain_, a zero trust domain governed by a single trust
1603          anchor and communications schema which is enforced at run-time by
1604          a library (e.g., DCT) using a signed binary copy of the schema at
1605          each member.  Nothing is accepted without validation; non-
1606          conforming communications are silently discarded.  As the schema
1607          cert is signed by the trust anchor, a trust comain is uniquely
1608          identified by the schema cert's thumbprint.  Where context is
1609          clear, just _domain_ may be used.
1610       *  trust-based Relay: (or just Relay) a special-purpose entity that
1611          connects a trust domain across different subnets

1613    8.  Security Considerations

1615       This document presents a transport protocol that secures the
1616       information it conveys (COMSEC in the language of [RFC3552]).
1617       Security of data in the application space is out-of-scope for this
1618       document, but use of a trusted execution environment (TEE), e.g.,
1619       ARM's TrustZone, is recommended where this is of concern.

1621       Unauthorized changes to DeftT code could bypass validation of
1622       received PDUs or modify the content of outgoing PDUs prior to signing
1623       (but only valid PDUs are accepted at receiver; invalid PDUs are
1624       dropped by uncompromised member).  Although securing DeftT's code is
1625       out-of-scope for this document, DeftT has been designed to be easily
1626       deployed with a TEE.  Revisiting Figure 4, Figure 16 highlights how
1627       all of the DeftT code and data can be placed in the secure zone
1628       (long-dashed line), reachable _only_ via callgates for the Publish
1629       and Subscribe API calls.

1631       (Artwork only available as svg: figs/hwtrust-rfc.svg)

1633           Figure 16: DeftT secured with a Trusted Execution Environment

1635       Providing crypto functions is out-of-scope of this document.  The
1636       example implementation uses *libsodium*, an open source library
1637       maintained by experts in the field [SOD].  Crypto functions used in
1638       any alternative implementation should be of similar high quality.

1640       Enrollment of devices is out of scope.  A range of solutions are
1641       available and selection of one is dependent on specifics of a
1642       deployment.  Example approaches include the Open Connectivity
1643       Foundation (OCF) onboarding and BRSKI [RFC8995].  NIST NCCOE network
1644       layer onboarding might be adapted, treating a communications schema
1645       like a MUD URL.

1647       Protecting private identity and signing keys is out-of-scope for this
1648       document.  Good key hygiene should be practiced, securing private
1649       credentials using best practices for a particular application class,
1650       e.g.  [COMIS][OWASP].

1652       DeftT's unit of information transfer is a Publication.  It is an
1653       atomic unit sized to fit in a lower layer transport PDU (if needed,
1654       fragmentation and reassembly are done in shim or application).  All
1655       Publications must be signed and the signature must be validated.  All
1656       Publications start with a Name (Section 2.3.1).  Publications are
1657       used both for ephemeral communication, like commands and status
1658       reports, and long-lived information like certs.  The set
1659       reconciliation-based syncps protocol identifies Publications using a
1660       hash of the _entire_ Publication, including its signature.  A sync
1661       collection can contain at most one instance of any Publication so
1662       replays of Publications in the collection are discarded as duplicates
1663       on arrival.  The current DeftT implementation requires weakly
1664       synchronized clocks with a known maximum skew.  Publications have a
1665       lifetime enforced by their sync collection; their names include a
1666       timestamp used both to enforce that lifetime and prevent replay
1667       attacks by keeping a Publication in the local collection (but not
1668       advertising its existence) until its lifetime plus the skew has
1669       passed.  (Lifetimes in current applications range from days or years
1670       for certs to milliseconds for status and command communications).
1671       Publications arriving a skew time before their timestamp or a skew
1672       time plus lifetime after their timestamp are discarded.

1674       An attacker can modify, drop, spoof, or replay any DeftT PDU or
1675       Publication but DeftT is designed for this to have minimal effect.

1677       1.  modification - all DeftT cAdd PDUs must be either signed or AEAD
1678           encrypted with a securely distributed nonce group key.  This
1679           choice is specified in the schema and each DeftT checks at
1680           startup that one of these two properties holds for the schema and
1681           throws an error if not.

1683           *  for signed PDUs each receiving DeftT must already have the
1684              complete, fully validated signing chain of the signer or the
1685              PDU is dropped.  The signing cert must validate the PDU's
1686              signature or the PDU is dropped.

1688           *  for encrypted PDUs (and Publications) the symmetric group key
1689              is automatically and securely distributed using signing
1690              identities.  Each receiver uses its copy of the current
1691              symmetric key to validate the AEAD MAC and decrypt the PDU
1692              content.  Invalid or malformed PDUs and Publications are
1693              dropped.

1695           cState modification to continually send an older, less complete
1696           state in order to generate the sending of cAdds could create a
1697           DoS attack but counter measures could be implemented using
1698           available DeftT information in order to isolate that entity or
1699           remove it from the trust domain.

1701       2.  dropped PDUs - DeftT's sync protocol periodically republishes
1702           cState messages which results in (re)sending dropped cAdds.
1703           Unlike unicast transports, DeftT can and will obtain any
1704           Publications missing from its collection from any member that has
1705           a valid copy.

1707       3.  spoofing - DeftT uses a trust management engine that validates
1708           the signing.  Malformed Publications and PDUs are dropped as
1709           early as possible.

1711       4.  replay - A cAdd is sent in response to a specific cState, so a
1712           replayed cAdd that matches a current cState simply serves a
1713           retransmit of the cAdd's Publication which will be filtered for
1714           duplicates and obsolescence as described above.  A cAdd that
1715           doesn't match a current cState will be dropped on arrival.

1717       Peer member authentication in DeftT comes through the integrated
1718       trust management engine.  Every DeftT instance is started with an
1719       identity bundle that includes the domain trust anchor, the schema in
1720       certificate format signed by this trust anchor, and its own member
1721       identity chain with a private identity key and the chain signed at
1722       the root by trust anchor.  Members publish their identity chains
1723       before any Publications are sent.  The trust management engine
1724       unconditionally drops any Publication or PDU that does not have a
1725       valid signer or whose signer lacks the role or capabilities required
1726       for that particular Publication or PDU.

1728       DeftT takes a modular approach to signing/validation of its PDUs and
1729       Publications, so a number of approaches to integrity, authenticity,
1730       and confidentiality are possible (and several are available at
1731       [DCT]).  Security features that are found to have vulnerabilities
1732       will be removed or updated and new features are easily added.

1734       A compromised member of a trust domain can only build messages that
1735       match the role and attributes in its signing chain.  Thus, a
1736       compromised lightbulb can lie about its state or refuse to turn on,
1737       but it can't tell the front door to unlock or send camera footage to
1738       a remote location.  Multiple PDUs could be generated, resulting in
1739       flooding the subnet.  There are possible counter-measures that could
1740       be taken if some detection code is added to the current DeftT, but
1741       this is deferred for specific applications with specific types of
1742       threats and desired responses.

1744       The example encryption modules provide for encryption on both cAdd
1745       PDUs and Publications.  The latter _must_ be signed by the originator
1746       in addition to being encrypted.  This is not required for cAdd PDUs,
1747       so the specific entity that sent the cAdd cannot be determined but
1748       the Publications it carries _must_ be signed, even if not encrypted.
1749       In DeftT, any member can resend a Publication from any other member
1750       (without modification) so group encryption (in effect, group signing)
1751       is no different.  Some other encryption approaches are provided whose
1752       potential vulnerabilities are described with their implementations
1753       and a signed, encrypted approach is also available [DCT].

1755       DeftT relies on libsodium and linux random implementations with
1756       respect to entropy issues.  In general, these are quite application-
1757       dependent and should be further addressed for particular deployments.

1759    9.  IANA Considerations

1761       This document has no IANA actions.

1763    10.  Normative References

1765       [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
1766                  Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
1767                  <https://www.rfc-editor.org/info/rfc8799>.

1769       [RFC9119]  Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC.
1770                  Zuñiga, "Multicast Considerations over IEEE 802 Wireless
1771                  Media", RFC 9119, DOI 10.17487/RFC9119, October 2021,
1772                  <https://www.rfc-editor.org/info/rfc9119>.

1774    11.  Informative References

1776       [ATZ]      Ngabonziza, B., Martin, D., Bailey, A., Cho, H., and S.
1777                  Martin, "TrustZone Explained: Architectural Features and
1778                  Use Cases", 2016, <https://doi.org/10.1109/CIC.2016.065>.

1780       [CAvuln]   Marlinspike, M., "More Tricks for Defeating SSL in
1781                  Practice", 2009, <http://2015.hack.lu/archive/2009/moxie-
1782                  marlinspike-
1783                  some_tricks_for_defeating_ssl_in_practice.pdf>.

1785       [CHPT]     CheckPoint, "The Dark Side of Smart Lighting: Check Point
1786                  Research Shows How Business and Home Networks Can Be
1787                  Hacked from a Lightbulb", February 2020,
1788                  <https://www.globenewswire.com/news-
1789                  release/2020/02/05/1980090/0/en/The-Dark-Side-of-Smart-
1790                  Lighting-Check-Point-Research-Shows-How-Business-and-Home-
1791                  Networks-Can-Be-Hacked-from-a-Lightbulb.html>.

1793       [CIDS]     OperantNetworks, "Cybersecurity Intrusion Detection System
1794                  for Large-Scale Solar Field Networks", 2021,
1795                  <https://www.sbir.gov/sbirsearch/detail/2104327>.

1797       [COMIS]    Lydersen, L., "Commissioning Methods for IoT", February
1798                  2019,
1799                  <https://www.silabs.com/documents/public/presentations/ew-
1800                  2019-iot-security-commissioning-methods-for-iot.pdf>.

1802       [COST]     Guy, W., "Wireless Industrial Networking Alliance, Wired
1803                  vs. Wireless: Cost and Reliability", October 2005,
1804                  <https://www.fierceelectronics.com/embedded/wired-vs-
1805                  wireless-cost-and-reliability>.

1807       [ConfusedDep]
1808                  Support, G. C., "Additional authenticated data guide",
1809                  July 2021, <https://cloud.google.com/kms/docs/additional-
1810                  authenticated-data#confused_deputy_attack_example>.

1812       [DCT]      Pollere, "Defined-trust Communications Toolkit", 2022,
1813                  <https://github.com/pollere/DCT>.

1815       [DER]      NERC, "North American Electric Reliability Corporation:
1816                  Distributed Energy Resources: Connection, Modeling, and
1817                  Reliability Considerations", February 2017,
1818                  <https://www.nerc.com/pa/RAPA/ra/
1819                  Reliability%20Assessments%20DL/
1820                  Distributed_Energy_Resources_Report.pdf>.

1822       [DIFF]     Eppstein, D., Goodrich, M. T., Uyeda, F., and G. Varghese,
1823                  "What's the difference?: efficient set reconciliation
1824                  without prior context", 2011.

1826       [DIGN]     Bandyk, M., "As Dominion, others target 80-year nuclear
1827                  plants, cybersecurity concerns complicate digital
1828                  upgrades", November 2019,
1829                  <https://www.utilitydive.com/news/as-nuclear-plants-look-
1830                  to-digitize-controls-and-enhance-performance-
1831                  cyber/566478/>.

1833       [DLOG]     Li, N., Grosof, B., and J. Feigenbaum, "Delegation logic",
1834                  February 2003, <https://doi.org/10.1145/605434.605438>.

1836       [DMR]      al., M. C. E., "Device Management Requirements to Secure
1837                  Enterprise IoT Edge Infrastructure", April 2021,
1838                  <https://www.wwt.com/white-paper/device-management-
1839                  requirements-to-secure-enterprise-iot-edge-
1840                  infrastructure/>.

1842       [DNMP]     Nichols, K., "Lessons Learned Building a Secure Network
1843                  Measurement Framework Using Basic NDN", September 2019.

1845       [DTM]      Blaze, M., Feigenbaum, J., and J. Lacy, "Decentralized
1846                  Trust Management", June 1996,
1847                  <https://doi.org/10.1109/SECPRI.1996.502679>.

1849       [Demers87] Demers, A. J., Greene, D. H., Hauser, C., Irish, W.,
1850                  Larson, J., Shenker, S., Sturgis, H. E., Swinehart, D. C.,
1851                  and D. B. Terry, "Epidemic Algorithms for Replicated
1852                  Database Maintenance", 1987,
1853                  <https://doi.org/10.1145/41840.41841>.

1855       [Graphene] Ozisik, A. P., Andresen, G., Bissias, G., Houmansadr, A.,
1856                  and B. N. Levine, "Graphene: A New Protocol for Block
1857                  Propagation Using Set Reconciliation", 2017,
1858                  <https://doi.org/10.1007/978-3-319-67816-0\_24>.

1860       [Graphene19]
1861                  Ozisik, A. P., Andresen, G., Levine, B. N., Tapp, D.,
1862                  Bissias, G., and S. Katkuri, "Graphene: efficient
1863                  interactive set reconciliation applied to blockchain
1864                  propagation", 2019,
1865                  <https://doi.org/10.1145/3341302.3342082>.

1867       [HSE]      Kapersky, "Secure Element", 2022,
1868                  <https://encyclopedia.kaspersky.com/glossary/secure-
1869                  element/>.

1871       [IAWS]     Ganapathy, K., "Using a Trusted Platform Module for
1872                  endpoint device security in AWS IoT Greengrass", November
1873                  2019, <Using a Trusted Platform Module for endpoint device
1874                  security in AWS IoT Greengrass>.

1876       [IBLT]     Goodrich, M. T. and M. Mitzenmacher, "Invertible bloom
1877                  lookup tables", 2011,
1878                  <https://doi.org/10.1109/Allerton.2011.6120248>.

1880       [IEC]      IEC, "Power systems management and associated information
1881                  exchange - Data and communications security - Part 8:
1882                  Role-based access control for power system management",
1883                  2022, <https://webstore.iec.ch/publication/61822>.

1885       [IEC61850] Wikipedia, "IEC 61850", 2021,
1886                  <https://en.wikipedia.org/wiki/IEC_61850>.

1888       [IIOT]     Rajiv, "Applications of Industrial Internet of Things
1889                  (IIoT)", June 2018, <https://www.rfpage.com/applications-
1890                  of-industrial-internet-of-things/>.

1892       [IOTK]     Nichols, K., "Trust schemas and {ICN:} key to secure home
1893                  IoT", 2021, <https://doi.org/10.1145/3460417.3482972>.

1895       [ISO9506MMS]
1896                  ISO, "Industrial automation systems --- Manufacturing
1897                  Message Specification --- Part 1: Service definition",
1898                  2003, <https://www.iso.org/obp/ui/#iso:std:iso:9506:-1:ed-
1899                  2:v1:en>.

1901       [LANG]     LANGSEC, "LANGSEC: Language-theoretic Security "The View
1902                  from the Tower of Babel"", 2021, <http://langsec.org>.

1904       [MATR]     Alliance, C. S., "Matter is the foundation for connected
1905                  things", 2021, <https://buildwithmatter.com/>.

1907       [MHST]     Wikipedia, "MQTT", 2022,
1908                  <https://en.wikipedia.org/wiki/MQTT>.

1910       [MINSKY03] Minsky, Y., Trachtenberg, A., and R. Zippel, "Set
1911                  reconciliation with nearly optimal communication
1912                  complexity", 2003,
1913                  <https://doi.org/10.1109/TIT.2003.815784>.

1915       [MODOT]    Saleem, D., Granda, S., Touhiduzzaman, M., Hasandka, A.,
1916                  Hupp, W., Martin, M., Hossain-McKenzie, S., Cordeiro, P.,
1917                  Onunkwo, I., and D. Jose, "Modular Security Apparatus for
1918                  Managing Distributed Cryptography for Command and Control
1919                  Messages on Operational Technology Networks (Module-OT)",
1920                  January 2022,
1921                  <https://www.nrel.gov/docs/fy22osti/79974.pdf>.

1923       [MPSR]     Mitzenmacher, M. and R. Pagh, "Simple multi-party set
1924                  reconciliation", 2018.

1926       [MQTT]     OASIS, "MQTT: The Standard for IoT Messaging", 2022,
1927                  <mqtt.org>.

1929       [NDNS]     NDN, "Named Data Networking Packet Format Specification
1930                  0.3", 2022,
1931                  <https://named-data.net/doc/NDN-packet-spec/current/>.

1933       [NDNW]     Jacobson, V., "Watching NDN's Waist: How Simplicity
1934                  Creates Innovation and Opportunity", July 2019,
1935                  <http://ice-ar.named-data.net/meetings/2019-ICE-WEN-
1936                  Annual/0-ICNWEN-Van-Keynote.pdf>.

1938       [NERC]     NERC, "Emerging Technology Roundtable - Substation
1939                  Automation/IEC 61850", November 2016,
1940                  <https://www.nerc.com/pa/CI/Documents/roundtable%20-%20IEC
1941                  %2061850%20slides%20%20(20161115).pdf>.

1943       [NMUD]     al, D. D. E., "Securing Small-Business and Home Internet
1944                  of Things (IoT) Devices: Mitigating Network-Based Attacks
1945                  Using Manufacturer Usage Description (MUD)", May 2021,
1946                  <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
1947                  NIST.SP.1800-15.pdf>.

1949       [NPPI]     Hashemian, H. M., "Nuclear Power Plant Instrumentation and
1950                  Control", 2011, <https://cdn.intechopen.com/pdfs/21051/InT
1951                  echNuclear_power_plant_instrumentation_and_control.pdf>.

1953       [NVR]      Gutmann, P., "Everything you Never Wanted to Know about
1954                  PKI but were Forced to Find Out", 2002,
1955                  <https://www.cs.auckland.ac.nz/~pgut001/pubs/
1956                  pkitutorial.pdf>.

1958       [ONE]      OneDM, "One Data Model", 2022, <https://onedm.org/>.

1960       [OPR]      King, R., "Commercialization of NDN in Cybersecure Energy
1961                  System Communications video", 2019, <https://www.nist.gov/
1962                  news-events/events/2019/09/ndn-community-meeting>.

1964       [OSCAL]    NIST, "OSCAL: the Open Security Controls Assessment
1965                  Language", 2022, <https://pages.nist.gov/OSCAL/>.

1967       [OTPM]     Hinds, L., "Keylime - An Open Source TPM Project for
1968                  Remote Trust", November 2019,
1969                  <https://www.youtube.com/watch?v=YtPsruEqGeY>.

1971       [OWASP]    owasp.org/www-project-sidekek/, "SideKEK README", June
1972                  2020, <https://github.com/OWASP/SideKEK>.

1974       [PRAG]     e}bowicz, J. W., Cabaj, K., and J. Krawiec, "Messaging
1975                  Protocols for IoT Systems---A Pragmatic Comparison", 2021,
1976                  <https://www.mdpi.com/1424-8220/21/20/6904>.

1978       [QTPM]     Arthur, D. C. W., "Quick Tutorial on TPM 2.0", January
1979                  2015, <https://link.springer.com/
1980                  chapter/10.1007/978-1-4302-6584-9_3>.

1982       [RFC2693]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,
1983                  B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
1984                  DOI 10.17487/RFC2693, September 1999,
1985                  <https://www.rfc-editor.org/info/rfc2693>.

1987       [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
1988                  Text on Security Considerations", BCP 72, RFC 3552,
1989                  DOI 10.17487/RFC3552, July 2003,
1990                  <https://www.rfc-editor.org/info/rfc3552>.

1992       [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1993                  Resource Identifier (URI): Generic Syntax", STD 66,
1994                  RFC 3986, DOI 10.17487/RFC3986, January 2005,
1995                  <https://www.rfc-editor.org/info/rfc3986>.

1997       [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
1998                  Architecture", RFC 4291, DOI 10.17487/RFC4291, February
1999                  2006, <https://www.rfc-editor.org/info/rfc4291>.

2001       [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
2002                  Cheshire, "Internet Assigned Numbers Authority (IANA)
2003                  Procedures for the Management of the Service Name and
2004                  Transport Protocol Port Number Registry", BCP 165,
2005                  RFC 6335, DOI 10.17487/RFC6335, August 2011,
2006                  <https://www.rfc-editor.org/info/rfc6335>.

2008       [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
2009                  Description Specification", RFC 8520,
2010                  DOI 10.17487/RFC8520, March 2019,
2011                  <https://www.rfc-editor.org/info/rfc8520>.

2013       [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
2014                  and K. Watsen, "Bootstrapping Remote Secure Key
2015                  Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
2016                  May 2021, <https://www.rfc-editor.org/info/rfc8995>.

2018       [RSK]      Ellison, C. and B. Schneier, "Ten Risks of PKI: What
2019                  You're Not Being Told About Public Key Infrastructure",
2020                  2000.

2022       [SDSI]     Rivest, R. L. and B. W. Lampson, "SDSI - A Simple
2023                  Distributed Security Infrastructure", April 1996.

2025       [SIOT]     Truong, T., "How to Use the TPM to Secure Your IoT/Device
2026                  Data", January 2017, <https://tonytruong.net/how-to-use-
2027                  the-tpm-to-secure-your-iot-device-data/>.

2029       [SKH]      Yates, T., "Secure key handling using the TPM", October
2030                  2018, <https://lwn.net/Articles/768419/>.

2032       [SNC]      Smetters, D. K. and V. Jacobson, "Securing Network
2033                  Content", October 2009, <https://named-data.net/wp-
2034                  content/uploads/securing-network-content-tr.pdf>.

2036       [SOD]      Bernstein, D., Lange, T., and P. Schwabe, "libsodium",
2037                  2022, <https://doc.libsodium.org/>.

2039       [SPRV]     AgendalessConsulting, "Supervisor: A Process Control
2040                  System", 2022, <http://supervisord.org/>.

2042       [ST]       Samsung, "SmartThings API (v1.0-PREVIEW)", 2020,
2043                  <https://smartthings.developer.samsung.com/docs/api-ref/
2044                  st-api.html##operation/listCapabilities>.

2046       [STNDN]    Yu, Y., Afanasyev, A., Clark, D. D., claffy, K., Jacobson,
2047                  V., and L. Zhang, "Schematizing Trust in Named Data
2048                  Networking", 2015.

2050       [TATT]     Microsoft, "TPM attestation", June 2021,
2051                  <https://docs.microsoft.com/en-us/azure/iot-dps/concepts-
2052                  tpm-attestation>.

2054       [TLSvuln]  al., C. B. E., "Using Frankencerts for Automated
2055                  Adversarial Testing of Certificate Validation in SSL/TLS
2056                  Implementations", November 2014,
2057                  <https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4232952/>.

2059       [TPM]      Griffiths, P., "TPM 2.0 and Certificate-Based IoT Device
2060                  Authentication", September 2020,
2061                  <https://www.globalsign.com/en/resources/white-papers-
2062                  ebooks/white-paper-tpm-20-and-certificate-based-iot-
2063                  device-authentication>.

2065       [W509]     Wikipedia, "X.509: Security", October 2021,
2066                  <https://en.wikipedia.org/wiki/X.509#Security>.

2068       [WSEN]     Kintner-Meyer, M., Brambley, M., Carlon, T., and N.
2069                  Bauman, "Wireless Sensors: Technology and Cost-Savings for
2070                  Commercial Buildings", 2002,
2071                  <https://www.aceee.org/files/proceedings/2002/data/papers/
2072                  SS02_Panel7_Paper10.pdf>.

2074       [WegmanC81]
2075                  Wegman, M. N. and L. Carter, "New Hash Functions and Their
2076                  Use in Authentication and Set Equality", 1981,
2077                  <https://doi.org/10.1016/0022-0000(81)90033-7>.

2079       [ZCL]      zigbeealliance, "Zigbee Cluster Library Specification
2080                  Revision 6", 2019, <https://zigbeealliance.org/wp-content/
2081                  uploads/2019/12/07-5123-06-zigbee-cluster-library-
2082                  specification.pdf>.

2084    Contributors

2086       Lixia Zhang
2087       UCLA
2088       Email: lixia@cs.ucla.edu

2090       Roger Jungerman
2091       Operant Networks Inc.

2093       Roger contributed much to Section 5.

2095    Authors' Addresses

2097       Kathleen Nichols
2098       Pollere LLC
2099       Email: nichols@pollere.net

2101       Van Jacobson
2102       UCLA
2103       Email: vanj@cs.ucla.edu

2105       Randy King
2106       Operant Networks Inc.
2107       Email: randy.king@operantnetworks.com