[core] draft-amsuess-core-repeat-request-tag

[Jim Schaad]

I have some comments on the draft based on a first read.


* Section 2.1 - Why is this a 64-bit value? In the case of end-to-end
security, this could be a single byte assuming that only 256 requests would
be outstanding for that security context.

* Section 2.1 - The fact that you need to distinguish between the name of
the option and the bit flags indicates that the name should probably be
changed.

I need to sit down and work out the flows for the Request-Tag and ETag
options. I think that there may be a missing security consideration on
ETag, but I need to figure out exactly how things work first.

jim

[Göran Selander]

Good comments, inline.

Post by Jim Schaad
I have some comments on the draft based on a first read.
* Section 2.1 - Why is this a 64-bit value? In the case of end-to-end
security, this could be a single byte assuming that only 256 requests would
be outstanding for that security context.

Remember that one use of this option is for securely synchronising state,
e.g. a sequence number to prevent from a replay attack in case of loss of
power. If we think that sequence numbers can be used in a simple way to
prevent this, then we should probably do that in the first place :-)

We did consider more complicated processing and smaller value but then
settled for the simple protocol and the larger value. If you think this
can be made simple enough by just enumerating values please make a pull
request.

Post by Jim Schaad
* Section 2.1 - The fact that you need to distinguish between the name of
the option and the bit flags indicates that the name should probably be
changed.

It may be obvious, but we didn’t think about it until just before
submission that there may be a potential confusion between the name of the
option “Repeat” and the property of an option being “Repeatable”, which is
the reason for the text in 2.1. If people think this is an issue we should
of course change the name. (Let's take the discussion of what the name
should be off-list, since there is a tendency to spend more time naming
things rather than discussing how things work :-)

Post by Jim Schaad
I need to sit down and work out the flows for the Request-Tag and ETag
options. I think that there may be a missing security consideration on
ETag, but I need to figure out exactly how things work first.

Please do, the analogy between Request-Tag and ETag is another thing we
have been thinking about. Christian may want to add something here.

Thanks
Göran

[Carsten Bormann]

I agree that the name “Repeat” is both confusing and non-descriptive — this option is not about repeating anything.
Freshness Token is more like it.

2.2: What is an "empty CoAP request”?
(A CoAP message can be empty or can carry a request, but cannot be both.)

I’m not sure that the requirement for a 64-bit or larger value is justified; it is the application that defines its freshness requirements, and if the freshness requirement is just about avoiding unnecessary work, a smaller freshness token may be just fine.

There might be other ways to derive/convey a freshness token; maybe it’s worth thinking about how this option would interact with that.

Grüße, Carsten