On Tue, Aug 23, 2022 at 10:57:44AM +1200, Brian E Carpenter wrote:
> > In my reading of rfc8990 CDDL, an M_FLOOD message with an appended
> > signature would NOT be parsed as an rfc8990 flood-message CDDL name,
> > which in my book means it wouldnot be an rfc8990 flood message. Aka:
> > i do not see a way how _any_ encoding of a new signature option (or for
> > that any option) could be included into a flood-message so that prevous,
> > rfc8990 only implementations would still receive and interpret this
> > message as a flood message, but ignore the (signature) option.
>
> I don't agree, but I think is due to a fundamental question of how one
> interprets CDDL. It isn't a syntax definition that MUST be adhered to.
> It's only a data definition language.
If instead of CDDL, we would specify GRASP with ASCII art, would you also
say that the ASCII art is advisory, but not normative ?
I don't think this was ever how we thought of the ASCII art. I think it was
always mandatory, and if the ASCII art did not match what the protocol message
should look like, then that was a bug in the ASCII art.
Therefore, i argue that the CDDL needs to be as mandatory as ASCII art
is in IETF RFC, or it really does not make sense to use CDDL.
> As far as I know, people don't
> implement CBOR based protocols to adhere to a CDDL spec.
People do not implement IETF protocols to adhere to the ASCII art of the IETF
protocol RFC ?
> It's different in that respect to, say, a compiler writer using recursive
> decent through a BNF spec. Having played recently with two other
> formal definitions and corresponding implementations (the URI spec for
> rfc6874bis, and the SVG spec for RFC7996), I'm pretty sure that CDDL
> is different in that respect.
I am pretty sure there is also no automated tool-chain that can compile
code from ASCII art. But that does not mean that the hand written code
will not comply to the ASCII art.
Aka: tool chains are irrelevant for making the CDDL as normative as
ASCII art is/was.
> That said, it wasn't until after my second coffee today that I
> really got the .within stuff right. However, each occurrence of "any"
> in the CDDL seems to signal a place where the code has to be very
> pragmatic, during both the encoding and decoding of a message.
Not really. The better we make our RFCs in being very explicit how
to handle the any, the less the code has to be pragmatic. See also
draft-iab-protocol-maintenance
Aka: we need to be as explicit in specifying reaction to any
variation of a received message as we can in the RFC and not
punt to coders with wishy-washy terms like "postel principle".
To that extend, it is best to define appropriate CDDL names capturing
the different sub-structures of a message that have to be handled
differently. Aka: those that can be ignored, or those that would lead
to rejection of message or the like.
In this respect, i think CDDL makes life a lot easier than ASCII
art, but we simply need to write the right CDDL names and then
define in text the desired reception semantic against those CDDL
names.
> > I also do not think that we have good normative text in rfc8990 to
> > mandate that such an option MUST be ignore upon receipt. In fact, in our
> > discussions so far, we have not come up wih a generic encoding proposal
> > to distinguish options that MUST be ignored vs. those that MUST cause
> > ignoring or raising error against the message itself. That second goal
> > could IMHO only be achieved with a new MESSAGE_TYPE in rfc8990.
>
> I believe that is correct. If you send an unknown message, it will
> be dropped, and if unicast, the recipient MAY send M_INVALID.
> (Section 2.8.2 of RFC8990)
Well, my main point is that if someone sense an M_FLOOD message
with a signature option at the end of the message, then it will not
be recognized as a flood-message by an RFC8990 CDDL compliant receiver
(that does not know about any signature option). This is IMHO what
we must fix by introducing those e.g.: *grasp-option to the
already defined messages.
Unless a CDDL expert tells me i am syntactically wrong.
> If we want a signature to be mandatory-to-verify, it needs a new
> message type. That's an open question for the WG.
Agreed. My opininion is that the mandatory-to-verify is not at the
level of the flood-message, but at the objective definition level.
Aka: I would want to define DNS-SD objectives that MUST be signed,
and where also the certificate of the signer MUST
meet certain criteria.
With that use-case in mind, it would IMHO make sense to add to the
signature draft also a definition of that certificate objective with
which the certificate could be flooded. After all, without knowing
a certificate, one can not validate the signature, and i hate if we
have only handwaiving, for how the recipient could learn the certificate.
After all, if i flood some objective with signature (for example a service
announcement), and the only way how to learn the certificate is to
open a grasp/TLS connection to the originator (because TLS gives me
the cert and also validates it), then we have just
created a DDoS attack against a third party: I originate a signed GRASP
DNS-SD announcement for that poor third-party, that will then receive
a lot of TLS connection attempts from all other nodes.
Cheers
Toerless
> > explicitly introduce a new GRASP header field "sender ttl" which is not
> > modified during flooding but would be used by final receiver to
> > "reconstitute" the ttl field to then validate the CBOR.
> >
> > Any benefits you think this approach would have ?
>
> My reply: no. I think the detached mode works better.
>
> >
> > > > 4. We don't claim to have solved the general problem of key
> > > > distribution for multicast destinations, but in the ACP context it
> > > > seems likely that we can flood out the necessary public keys.
> > >
> > > I feel confident that for a number of use cases that this won't be an
> > > issue,
> > > and that we can leverage the BRSKI enrollment process to get any
> > > application
> > > specific keys that we need.
> >
> > Many network designs start with centralized servers and even struggle with
> > redundancy/failover of them. In ANIMA/ANI, we should always start with the
> > basic technology providing fully distributed mechanisms, such as the flood
> > message. When we then see cases where we can only scale futher by having
> > "coordination agents", then it is trivial to build them.
> >
> > Aka: If we had thousands of ANI nodes wanting to announce services, then we
> > would want to have some election mean for some of them to become
> > "coordination agents", so the thousands of nodes just send (unicast) to
> > those
> > "coordination agents", and these coordination agents then flood. (ASA/AF)
> >
> > This is pretty much what the redundant server based solutions do, except
> > that in the IoT space, they often have very ad-hoc rules who can be such
> > a server/coordination-agent. In ANI, we could ad-hoc say that if you're
> > a registrar, you do also do other coordination. Such as validating and
> > reflecting service announcements.
> >
> > All in good time. signature option is the most fundamental work to start
> > with.
>
> Agreed.
> Brian
>
> >
> > Cheers
> > toerless
> >
> > >
> > > --
> > > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> > > Sandelman Software Works Inc, Ottawa and Worldwide
> > >
> > >
> > >
> > >
> >
> >
> >
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
