On Sat, Aug 20, 2022 at 04:21:06PM -0400, Michael Richardson wrote:
>
> Brian E Carpenter <[email protected]> wrote:
> > We would prefer that this doesn't invalidate existing (unsigned) GRASP
> > code. That could be done by appending an optional signature to the
> > existing M_FLOOD message format. An alternative is to add a new flood
> > format that is signed, but would not be understood by existing code.
>
> A third option is that we make what might be a breaking change.
> A subject of some debate has been whether some of the proposed changes are in
> fact breaking changes to the spec, or just to how some code (mis)-intrepreted
> the spec.
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 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.
To me this all means that we have some good freedom to encode such option
as good as possible without having to bother with backward compatibility.
Instead we probably want to do it faster and make that an update of
rfc8990 so that not too many existing implementations are hit.
> At this point, my opinion is that we do not have enough GRASP deployment for
> this to matter. I think that having signed M_FLOOD messages, even if they
> are inside a protected ACP, is a sufficiently useful thing that we should
> just do that.
> I have one use case that involves Information Centric Networking (ICN) inside
> of an ACP.
I hope we can write the use-cases and missing dependencies into our
signature draft so its clear what it is good for.
For the ACP and flood messages, the signature is a core dependency
to allow service announcements to only be done by authorized nodes.
Beside signature option, this requires appropriate extension fields
in ACP certificates (which i guess exist in other RFC), and some
objective to flood nodes certificates (which could be together with
the service objective with signature in one packet).
> > 3. It seems fairly obvious that we should use COSE, most likely with a
> > detached payload, so that the M_FLOOD message appears unsigned for
> > nodes that don't support signing and verification.
>
> One possible breaking change would be to use COSE in non-detached payload
> mode.
flood messages are flooded by intervening GRASP nodes, so all those
GRASP nodes would have to parse across the COSE header, which they
would otherwise ignore, just to get to the GRASP message which they
would need to do the flooding for. Doesn't seem like a good fit tome.
Also, i think this approach is killed by the fact that we need to change
the ttl field of the GRASP message on every hop during flooding. I don't
think we could do this when we want to ignore the COSE header. Unless we
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 ?
> > 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.
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
