Changing subject as this is not directly related to the current
constrained-brski drafts..
On Thu, Apr 28, 2022 at 02:13:40PM +1200, Brian E Carpenter wrote:
> > Yes, was thinking of that, but instead of trying to invent what i'd call a
> > new lightweight
> > crypto header just use DTLS and TLS. So some similar or rewrite of that
> > proposal.
>
> TLS for the GRASP TCP sessions should be fine. The reason I did QUADS was
> because people told me that multicast DTLS was not a thing, but GRASP depends
> on multicast UDP.
But we only need unsecured link-local multicast fo DULL GRASP, but no other
multicast.
And instead of TLS we just use DTLS everywhere for GRASP, e.g.:
- link-local p2p DTLS insted link-local TCP over ACP secure channel
(because we have no ACP secure channel in such constrained networks)
- end-to-end p2p DTLS instead of end-to-end TLS over ACP secure channel
If we had a non-constrained network without ACP, we would do the same with TLS,
because ultimately DTLS is not less overhead than TLS, its just a religion
by some IoT folks.
Aka: just to recreate the ACP-GRASP experience without an ACP we could just
specify such a "constrained" DTLS and "unconstrained" TLS substrate option.
This is maybe a bit spec-it-and-hope-they-will-come, but obviously, the
overhead of a whole separate ACP is orders of magnitude higher than this
simple application-layer-only "service-management-daemon" (one way to sell
GRASP).
The not-as-easy-resolved-issue is IMHO selecting some way to authenticate
GRASP messages, e.g.: optional JOSE field in GRASP messages or the like.
And defining maybe some ACP certificate property that authorizes the
node to announce services. Those type of better-than-group-security would
be likely highly needed in those non-ACP deployments.
Cheers
Toerless
> Brian
>
> >
> > > That work is not ready for the standards track but it shows proof of
> > > concept, if you accept the need for a shared secret.
> >
> > Given how we would be pitching it to networks where devices are enrolled
> > with a certificate,
> > we would get zero-touch deployment by using that certificate. And we given
> > how we wouldn't
> > want to do address assignment, we might get away with non-enhanced
> > certificates.
> >
> > Its really the question where/how those constrained vouchers would be used
> > in mesh networks and what
> > gaps those mesh networks might have.
> >
> > 6TISCH for example seems like not having something useful for discovery
> > right now if i correctly
> > extrapolate MichaelR's last reply here.
> >
> > CHeers
> > Toerless
> >
> > >
> > > Regards
> > > Brian
> > >
> > > On 26-Apr-22 12:16, Toerless Eckert wrote:
> > > > On Wed, Apr 13, 2022 at 01:19:21PM -0400, Michael Richardson wrote:
> > > >
> > > > (1)
> > > >
> > > > > Yes, you are right, we need to have a new objective to announce.
> > > > > I guess that we don't really think about the constrained-join-proxy
> > > > > really
> > > > > being used in an ACP context, but we really should that right.
> > > >
> > > > I don't think this is true. As soon as EST-COAPS proliferates as an RFC,
> > > > the choice of TLS vs. COAPS becomes not only a necessity for constrained
> > > > devices, but also a preference choice by solution designers. Less code
> > > > modules etc.
> > > >
> > > > Also, RFC8995 promised the COAPS solution as part of ANI (the way i see
> > > > it).
> > > >
> > > > I always imagined in-ceiling network switches that do full ACP but
> > > > are also gateways to IoT edge networks as a good size candidate market
> > > > example.
> > > >
> > > > (2)
> > > >
> > > > Separate question: Do we have a good understanding which solution
> > > > that needs the constrained proxy will use which discovery mechanism ?
> > > >
> > > > I am asking because if/where there are gaps in supported discovery
> > > > mechanisms,
> > > > we might be able to suggest GRASP without ACP. Which would be somewhat
> > > > of another
> > > > draft..
> > > >
> > > > > https://github.com/anima-wg/constrained-join-proxy/issues/17
> > > > >
> > > > > > Note that it is not sufficient to delta RFC8995 and mention
> > > > > > "EST-COAPS", because the GRASP objective also needs to
> > > > > indicate UDP
> > > > > > instead of TCP. Even though it is longer, it would IMHO be
> > > > > prudent to
> > > > > > copy the whole GRASP objectives and examples from RFC8995 and
> > > > > > accordingly modify them, so that the constrained-proxy draft
> > > > > is
> > > > > > "standalone" in this respect (even if a page longer).
> > > > >
> > > > > I think you are asking us to show an example that advertises both
> > > > > RFC8995,
> > > > > and the constrained version, correct?
> > > >
> > > > (3)
> > > >
> > > > No. The example does not need to show both. Just constrained version as
> > > > a
> > > > standalone GRASP objective IMHO. I would suggest to clone the text from
> > > > RFC8995 and accordingly modify it.
> > > >
> > > > > > Isn't there the thought that some other variations of BRSKI
> > > > > will use
> > > > > > protocol variations, such as not CBOR+JSON ? some other "CMP"
> > > > > encoding
> > > > > > ?
> > > > >
> > > > > We decided that Registrars will be responsible for interoperation,
> > > > > and will
> > > > > support all protocols the operator expects to use. If you buy a
> > > > > Registrar
> > > > > that does not do X and a pledge that only does X, then it fails, and
> > > > > you were
> > > > > stupid.
> > > >
> > > > (4)
> > > >
> > > > In the first place this needs to be written down.
> > > >
> > > > But i'd rather like to argue it away because i think it is an
> > > > unnecessary
> > > > constraining "hack".
> > > >
> > > > Why have all this discovery mechanisms when they are not even used
> > > > correctly.
> > > > Underspecifying the exact service(s) a Registrar offers is like
> > > > announcing
> > > > "Oh, go to google for the WHATEVER services".
> > > >
> > > > I don't see that implementations would get more complex, but rather
> > > > simpler if we simply are able to distinguish the different protocol
> > > > options
> > > > by their service name/parameters and have proxies/clients be able to
> > > > select
> > > > them.
> > > >
> > > > At least thats my opening offer, lets discuss ;-) But see below.
> > > >
> > > > > > I am asking, because it seems to me we need to be aware, that
> > > > > the
> > > > > > constrained-proxy is logically "just" a DTLS proxy, but once
> > > > > we have
> > > > > > more than one DTLS BRSKI variation, we still need to be able
> > > > > for
> > > > > > pledges to connect to registrar(s) that talk the BRSKI
> > > > > variation that
> > > > > > the pledge supports. What we define here initially is
> > > > > effectively
> > > > > > proxy/registrar for EST-COAPS. So let's assume, we get another
> > > > > > protocol, OTHER1-DTLS. The constrained proxy continues to
> > > > > work, but it
> > > > > > would now need to discover the OTHER1-DTLS Registrar,
> > > > > allocate a new
> > > > > > UDP port number on which to offer proxy services for
> > > > > OTHER1-DTLS and
> > > > > > announce that to pledges.
> > > > >
> > > > > You aren't wrong, but you also aren't right.
> > > > > Pledges are expected to try all options (possibly concurrently if
> > > > > they have
> > > > > CPU/ram) until they find one that works. There is no reason the
> > > > > join proxy
> > > > > needs to know the details of the Registrar supports, only that they
> > > > > support a
> > > > > way to talk to it.
> > > >
> > > > (5)
> > > >
> > > > That "trial&error" too should be described if its here to stay. Even if
> > > > just
> > > > through a reference to an appropriate section in 8995 (if its in there,
> > > > not sure).
> > > >
> > > > (6)
> > > >
> > > > How about cert renewal, did you folks discuss if this would ever be
> > > > something
> > > > pledges would want to do through the proxy ? In the case of ACP we did
> > > > discuss this, and i thinkit's in 8994 as well. E.g.: when cert is
> > > > expired, so
> > > > the enrolled device can not wield its cert for secure network access,
> > > > but its
> > > > still good enough for renewal.
> > > >
> > > > > > I wonder if the names choosen for est-coaps discovery,
> > > > > brski.jp and
> > > > > > brski.rjp are ideal indicative of the fact that we're rather
> > > > > defining
> > > > > > brski-est-coaps.jp and brski-est-coaps.rjp. I guess
> > > > > beauty/explicitness
> > > > >
> > > > > Fair point.
> > > >
> > > > (7)
> > > >
> > > > I guess a compromise for (4) would be new text that leaves the decision
> > > > for
> > > > how to deal with the next enrollment protocol/encoding to such a
> > > > followu draft:
> > > >
> > > > IF implementers of a new variant feel that all existing/deployed
> > > > registrars
> > > > will and should be able to support the new protocol variant (e.g.:
> > > > brski-xmp-xyz),
> > > > then that protocol option does not need to come up with a new variation.
> > > >
> > > > IF implementers feel that is not appropriate, then:
> > > > a) A new set of service names is required (brski-xmp-xyz.jp/rjp or the
> > > > like)
> > > > b) constrained proxies supporting both the new and the old will have to
> > > > effectively run separate instances for them, e.g.: each instance
> > > > having
> > > > a separate UDP port number towards the pledge and using separate
> > > > service names from registrar and to proxy.
> > > >
> > > > > > 3. 6tisch discovery
> > > > >
> > > > > > [I-D.ietf-6tisch-enrollment-enhanced-beacon] is now RFC9032,
> > > > > please
> > > > > > update draft accordingly.
> > > > >
> > > > > > Upon quick browse of RFC9032 i fail to see how/where RFC9032
> > > > > would be
> > > > > > able to deal with more than one discovery protocol. E.g.: How
> > > > > would we
> > > > > > discover BRSKI-EST-COAPS-REGISTRAR BRSKI-EST-COAPS-PROXY
> > > > > > OTHER1-DTLS-REGISTRAR OTHER1-DTLS-PROXY
> > > > >
> > > > > Yes, are you right.
> > > > > RFC9032 does not support DTLS at all.
> > > > > It supports RFC9031 only.
> > > > > Perhaps we should simply indicate that we don't support 6TISCH.
> > > >
> > > > No opinion. Sounds like the easiest solution, unless you do want some
> > > > way to support 6TISCH ?
> > > >
> > > > > > 4. Stateful vs. stateless proxy discovery
> > > > >
> > > > > > How do i know as a customer of equipment know that all my
> > > > > > pledges/proxies/registrars will interoperate in the face of
> > > > > those
> > > > > > devices seemingly being able to freely pick stateful and/or
> > > > > stateless
> > > > > > mode of operations ?
> > > > >
> > > > > Because, we defined the proxy to have a standard interface.
> > > >
> > > > What does that mean ? Do all proxies need to support both modes, or
> > > > is there only the requirement for one mode, but some undefined entity
> > > > has to
> > > > figue out what registrar/proxies in some network should decide to use ?
> > > >
> > > > > (Except for CoAP/OSCORE vs CoAPS above)
> > > >
> > > > OSCORE = ?
> > > >
> > > > > How the join proxy keeps state (in memory or in the network) is a
> > > > > private
> > > > > matter between the JP and the Registrar, and does not concern the
> > > > > pledge.
> > > >
> > > > Cheers
> > > > Toerless
> > > >
> > > > > --
> > > > > ] Never tell me the odds! | ipv6 mesh
> > > > > networks [
> > > > > ] Michael Richardson, Sandelman Software Works | network
> > > > > architect [
> > > > > ] [email protected] http://www.sandelman.ca/ | ruby on
> > > > > rails [
> > > > >
> > > > >
> > > > > --
> > > > > Michael Richardson <[email protected]>, Sandelman Software Works
> > > > > -= IPv6 IoT consulting =-
> > > >
> > > > _______________________________________________
> > > > Anima mailing list
> > > > [email protected]
> > > > https://www.ietf.org/mailman/listinfo/anima
> > > >
> >
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
