Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
Toerless Eckert wrote: > Could as well simply be a function which buffers flood-messages over a > period of e.g.: 60 seconds and coalesces them together, so it's > transparent to the originators (loose coupling). > So, now i have a single flood-message with multiple objectives, each > objective requiring its own signature, because it comes from a > different originator/certificate. I can buy this example. I think that the cost of the flood across the wired/powered part of the network is low, and the number of messages we can coalesce is not that many. at least ~50 bytes per message, given a 32-byte EcDSA signature. That's still a 20:1 ratio though, and nothing to sneeze at. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
Toerless Eckert wrote: > On Wed, Aug 24, 2022 at 08:33:43PM -0400, Michael Richardson wrote: >> >> Brian E Carpenter wrote: > I need to >> understand epochs a bit better. I wonder whether an epoch > boundary >> should define when session-id repetition becomes OK (even if > highly >> improbable). There's a practical argument for that: a good > >> implementation will cache obsolete session-ids to detect repetition, > >> but needs to age out that cache somehow. My code does that with a > >> simple LRU but that isn't ideal. >> >> That's totally a good idea. is: >> https://www.ietf.org/archive/id/draft-ietf-rats-architecture-21.html#name-example-3-epoch-id-based-pa >> helpful? > How do you think Rats epoch-id is different from Grasp session-id, > where each originator in grasp simply has its own epoch-id space > (because the session-ids from each originator are in context of that > originator) ? Ah. A trusted third party would rain Epoch IDs down on all nodes, both transmitters and receivers. They could use signed M_FLOODs.yes, that creates a circular problem, but the EpochIDs could be arranged to be a hash list, a la S/Key. > I couldn't find reasonable examples of how often epoch-ids in rats > would be changed, so i have a hard time coming up with a qualitative > comparison. It's a good question, and the answer depends upon how things will be used. I would envision a new Epoch every few minutes to every few hours. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
On Wed, Aug 24, 2022 at 08:33:43PM -0400, Michael Richardson wrote: > > Brian E Carpenter wrote: > > I need to understand epochs a bit better. I wonder whether an epoch > > boundary should define when session-id repetition becomes OK (even if > > highly improbable). There's a practical argument for that: a good > > implementation will cache obsolete session-ids to detect repetition, > > but needs to age out that cache somehow. My code does that with a > > simple LRU but that isn't ideal. > > That's totally a good idea. > is: > https://www.ietf.org/archive/id/draft-ietf-rats-architecture-21.html#name-example-3-epoch-id-based-pa > helpful? How do you think Rats epoch-id is different from Grasp session-id, where each originator in grasp simply has its own epoch-id space (because the session-ids from each originator are in context of that originator) ? To me it looks very much the same, especially given the implied way how to deal with session-id (as explained by Brian above). I couldn't find reasonable examples of how often epoch-ids in rats would be changed, so i have a hard time coming up with a qualitative comparison. Cheers toerless ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
On Wed, Aug 24, 2022 at 04:57:21PM -0400, Michael Richardson wrote: > > What I don’t understand is why the signature then needs to be encoded > > as part of the objective. Why can’t I sign a combination of objectives > > that are only valid as that combination? > > I think it could go somewhere else, but I'd like to first understand an > example of this combination. Assume i have a "controller" that is connected to a low-power network with grasp. Think of something like a central device in a thread network or the like with an app model to add services. Worst case (today). Every group of devices from every vendor needs its own separate app to be controlled. The controller has a model where each "app" gets its own domain certificate, e.g. think ANI/ACP certificate, each with appropriate authorization attribute. GRASP goes though the common controller core. To minimize energy consumption in the low-power netwokr, it aggregates the flooded objectives. Fewer multicast flooded messages means less energy consumption. My proprietary german system (homematic IP) does for example defines strict limits on number of messages to be able to give lifetime expectations for client devices batteries. Could as well simply be a function which buffers flood-messages over a period of e.g.: 60 seconds and coalesces them together, so it's transparent to the originators (loose coupling). So, now i have a single flood-message with multiple objectives, each objective requiring its own signature, because it comes from a different originator/certificate. Cheers Toerless ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
Brian E Carpenter wrote: > I need to understand epochs a bit better. I wonder whether an epoch > boundary should define when session-id repetition becomes OK (even if > highly improbable). There's a practical argument for that: a good > implementation will cache obsolete session-ids to detect repetition, > but needs to age out that cache somehow. My code does that with a > simple LRU but that isn't ideal. That's totally a good idea. is: https://www.ietf.org/archive/id/draft-ietf-rats-architecture-21.html#name-example-3-epoch-id-based-pa helpful? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
On 25-Aug-22 08:57, Michael Richardson wrote:
Carsten Bormann wrote:
> That is getting closer to my question “what does it mean for
> (something) to be signed”?
> Apparently, this is a statement from an initiator, valid within the
> session-id, optionally scoped to the locator option, and expressed in
> the objective. These four are picked out of the message. The
> mechanism is specific to M_FLOOD and needs to be re—done for any other
> message type.
> The signed-data is missing a freshness component, which is either an
> absolute timestamp (like CWT exp, possibly enhanced with nbf/iat info)
> or an epoch marker.
Yes. Toerless thinks it might be contained in the session-id, but I've been
sitting on the fence about that.
Well (as you can see in Toerless's proposal) the tuple {session-id, initiator}
needs to be included, because theoretically two initiators could generate
the same pseudo-random session-id.
I need to understand epochs a bit better. I wonder whether an epoch boundary
should define when session-id repetition becomes OK (even if highly improbable).
There's a practical argument for that: a good implementation will cache
obsolete session-ids to detect repetition, but needs to age out that cache
somehow. My code does that with a simple LRU but that isn't ideal.
Brian
> We want the objective to stand alone for forward compatibility; hence
> the signature would have a detached payload.
> What I don’t understand is why the signature then needs to be encoded
> as part of the objective. Why can’t I sign a combination of objectives
> that are only valid as that combination?
I think it could go somewhere else, but I'd like to first understand an
example of this combination.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
Carsten Bormann wrote: > That is getting closer to my question “what does it mean for > (something) to be signed”? > Apparently, this is a statement from an initiator, valid within the > session-id, optionally scoped to the locator option, and expressed in > the objective. These four are picked out of the message. The > mechanism is specific to M_FLOOD and needs to be re—done for any other > message type. > The signed-data is missing a freshness component, which is either an > absolute timestamp (like CWT exp, possibly enhanced with nbf/iat info) > or an epoch marker. Yes. Toerless thinks it might be contained in the session-id, but I've been sitting on the fence about that. > We want the objective to stand alone for forward compatibility; hence > the signature would have a detached payload. > What I don’t understand is why the signature then needs to be encoded > as part of the objective. Why can’t I sign a combination of objectives > that are only valid as that combination? I think it could go somewhere else, but I'd like to first understand an example of this combination. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
The use case that led me to start some of this discussion was that of using Information Centric Networking in emergency situations. A key observation that many have made is that backup/emergency systems need constant maintenance and testing, and if they aren't used regularly then they tend to rot. This leads to the view that if a converged network can be made resilient enough to be used during emergencies, then there are a number of advantages: a) it probably has more than enough capacity for the emergency traffic! b) if it breaks, then someone will notice, and there is an incentive to fix it c) many situations which aren't full on emergencies benefit from the resiliency I looked through some documents, such as: https://www.rfc-editor.org/rfc/rfc7945.html#section-3 https://www.rfc-editor.org/rfc/rfc8884.html Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios Read the requirements at: https://www.rfc-editor.org/rfc/rfc8884.html#section-3.3 and compare them to what GRASP offers? In thinking about building automation IoT systems, the ICN approach is rather useful. In it, one does not tell a light switch which light bulbs to control, but rather tells a light bulb what senses should be relevant to it. The sensors then simply announce their state, and the bulbs respond. In a converged building network, where there might be many hundred Gb/s of bandwidth for the tenants to use, the sensor network could be accomodated by a series of gateways which translate between 802.15.4 radios or BACnet, and a fiber-optic backbone. But the control network needs to be protected from the rest of the traffic, and isn't that what the ACP does? Is there that much difference between learning that an optical module has gone bad via SNMP/NETCONF over ACP, and learning that the elevator door is damaged and won't close, so elevator 14 is out of service, over BACnet? (Could the two be related?) So in the view that the resiliency of the control network must be continuously be tested, then the right answer is to use the control (ACP) network for all the automation functions. Of course we can run DTLS for MQTT and the like over the ACP, and for many things we probably should do that, but we also need all the caching and flooding mechanisms that GRASP offers. (particularly during a flood. Hmm. Some kind of RFC2616-like RFC about new M_FLOOD objectives for use during a flood ) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
On 2022-08-24, at 19:20, Toerless Eckert wrote: > > data-to-be-signed = [session-id, initiator, ?locator-option, objective ] That is getting closer to my question “what does it mean for (something) to be signed”? Apparently, this is a statement from an initiator, valid within the session-id, optionally scoped to the locator option, and expressed in the objective. These four are picked out of the message. The mechanism is specific to M_FLOOD and needs to be re—done for any other message type. The signed-data is missing a freshness component, which is either an absolute timestamp (like CWT exp, possibly enhanced with nbf/iat info) or an epoch marker. We want the objective to stand alone for forward compatibility; hence the signature would have a detached payload. What I don’t understand is why the signature then needs to be encoded as part of the objective. Why can’t I sign a combination of objectives that are only valid as that combination? Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
All for it, if we agree on the challenges with it (which i think are "easily" solved). My use-case is signing of objectives in flood-messages doing service announcements, e.g.: with my DNS-SD compatible approach (or any other approach). 1) We want the flooded message to be protected against replay attacks. The usual way to do this is to include some form of sequence-number / timestamp into the signed object. The existing grasp message element that could serve this purpose is the session-id. This is not in the objective. I think it's the most important choice anyhow to decide how to do replay protection / freshness. If we decide we can use the session-id, then we need to do some "virtual extended objective" against which the signature is done, which includes the session-id. I would be fine with it. Same think i think UDP does (or at least did in IPv4) for checksum. 2) Likewise, the signature MUST for the use-cases i am interested in protect the locator-option for the objective, because that locator-option is how the DDoS attack would work, and if we want to permit third-party service announcements via flood-message, we at least want to make sure we know cryptographically who originated it. Aka, maybe solution is: Given an objective: data-to-be-signed = [session-id, initiator, ?locator-option, objective ] locator-option is included whenever it is also included in the flood-message together with the objective objective-with-signature = [ ~objective, signature(data-to-be-signed) ] Objectives just need to ensure that their format is such that tailing signatures can be recognized. Cheers Toerless On Wed, Aug 24, 2022 at 06:35:33PM +0800, Sheng Jiang wrote: > >If that's the case, we are on the wrong track. Should we be discussing > >signing GRASP objectives, rather than messages? > > Agreed. We can work on a mechanism that can sign objectives first. Later, > if there were use cases that signed objectives were not sufficient, we can > define a flood message. > > Sheng > > On Wed, 24 Aug 2022 at 07:02, Brian E Carpenter > wrote: > > > On 23-Aug-22 21:56, Toerless Eckert wrote: > > > > > Agreed. My opininion is that the mandatory-to-verify is not at the > > > level of the flood-message, but at the objective definition level. > > > > If that's the case, we are on the wrong track. Should we be discussing > > signing GRASP objectives, rather than messages? > > > > In many ways, that would be much easier to design and retro-fit. > > > > Brian > > > > ___ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > > -- > Sheng Jiang -- --- t...@cs.fau.de ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
>If that's the case, we are on the wrong track. Should we be discussing >signing GRASP objectives, rather than messages? Agreed. We can work on a mechanism that can sign objectives first. Later, if there were use cases that signed objectives were not sufficient, we can define a flood message. Sheng On Wed, 24 Aug 2022 at 07:02, Brian E Carpenter wrote: > On 23-Aug-22 21:56, Toerless Eckert wrote: > > > Agreed. My opininion is that the mandatory-to-verify is not at the > > level of the flood-message, but at the objective definition level. > > If that's the case, we are on the wrong track. Should we be discussing > signing GRASP objectives, rather than messages? > > In many ways, that would be much easier to design and retro-fit. > > Brian > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Sheng Jiang ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
Brian E Carpenter wrote: > On 23-Aug-22 21:56, Toerless Eckert wrote: >> Agreed. My opininion is that the mandatory-to-verify is not at the >> level of the flood-message, but at the objective definition level. > If that's the case, we are on the wrong track. Should we be discussing > signing GRASP objectives, rather than messages? That might better fit the goals. Probably we should have started with a few use cases. > In many ways, that would be much easier to design and retro-fit. cool. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]
On 23-Aug-22 21:56, Toerless Eckert wrote: Agreed. My opininion is that the mandatory-to-verify is not at the level of the flood-message, but at the objective definition level. If that's the case, we are on the wrong track. Should we be discussing signing GRASP objectives, rather than messages? In many ways, that would be much easier to design and retro-fit. Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
