On Mon, 18 Jul 2022, Daniel Migault wrote:
The limited SPI numbers and rekeying is still not clear to me.
We exchanged a few emails but that did not result in me understanding
this.
I am happy to understand what is unclear. I suppose the text you are referring
to is the one below - extracted from version 11.
Alternatively, some constrained devices will not implement IKEv2 or
Minimal IKEv2 and as such will not be able to manage a roll-over
between two distinct SAs. In addition, some of these constrained
devices are also likely to have a limited number of SAs - likely to
be indexed over 3 bytes only for example. One possible way to enable
a rekey mechanism with these devices is to use the SPI where for
example the first 3 bytes designates the SA while the remaining byte
indicates a rekey index. SPI numbers can be used to implement
tracking the inbound SAs when rekeying is taking place. When
rekeying a SPI, the new SPI could use the SPI bytes to indicate the
rekeying index.
I don't understand what it is that the devices are trying to do. Both in
terms of saving CPU or energy, and in terms of interpreting bytes of the
protocol. Can you give a full example of a rekey taking place in the
traditional way and in this new way proposed here? Perhaps when I see
that, I can help with modifying the above text to make this process
clear?
The sequence number discussion mentions the issue of packets falling
out of the receive window. We talked about an IKE option/notify to
signal this and during that discussion it also came to light that this
protocol is going to be used without IKEv2. This leaves an
interoprability unaddressed.
I do not see any mention of IKE option and SN, but maybe you can refresh my
memory.
Without signaling that this is going to use large jumps in the SN, the
other end would drop packets outside of its replay window. If there is
no IKE, how is the peer going to know about this? eg you write:
Note that standard receivers are generally configured with
incrementing counters and, if not appropriately configured, the use
of a significantly larger SN than the previous packet can result in
that packet falling outside of the peer's receiver window which could
cause that packet to be discarded.
What you wrote is "this is a problem". Instead, I think you should state
something like "Using time based SN should only be used when it is known
that the remote peer supports this or when it is known that anti-replay
windows are disabled".
The only IKE option discussion I recall of is an option you propose to
request the other peer not to send dummy packets - which is primarily out of
scope of minimal esp and whose usefulness remains to be proven.
It was in relation to AEAD security.
I did talk about using IKEv2 to convey some of these recommendations
via IKEv2 so peers can become aware of these instead of the more vague
wording the draft now uses that basically assumes all peers involved
do minimal ESP. It is fine for you not to take up this suggestion.
And since this protocol is also meant to run without IKEv2, there is
an issue of only recommending AEAD algorithms that rely on IKEv2 for
its security properties.
I do not see the issue associated with AEAD, so can you be a bit more explicit.
I do not see what is being provisioned via IKE that cannot be provisioned
via other means.
Sure, anything IKEv2 provides can be provided in another way. AEAD
normally relies on a protocol to ensure rekeying before a maximum
amount of crypto operations is done, ensures nonces and counters
are never re-used, and the same private key is not re-used when a
device reboots. I can (reluctantly) agree, you don't need to do
anything else in this document for this.
In addition, I do not see this as an issue if we were mandating AEAD. This is
not the case. The document recommends the use of AEAD as a general
purpose. I think this is relevant and does not prevent specific cases of not
using AEAD. What text would you like to see ?
Recommending or requiring are kind of the same thing with respect to
requirements to comply. As I said, no need to add text for AEAD.
Section 6 talks about Dummy packets but the labeling of the header
is a bit misleading into thinking the Next Header behaviour is
modified. I had suggested the section to be renamed.
The current title is "6. Next Header (8 bit) and Dummy Packets". The section
has been renamed, and I do not see what more needs to be done.
The entire section is ONLY about dummy packets. Which happen to get
indicated by a value contained in the Next Header. I find the title
of the section misleading because it appears to talk about Next Header
in general, especially when it starts talking about that it is a
mandatory field. Again, I'll treat that as a comment and not a blocking
issue, but the section should really just be called "Dummy Packets".
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
