Re: [Lwip] [IPsec] Paul Wouters' Discuss on draft-ietf-lwig-minimal-esp-08: (with DISCUSS and COMMENT)

[Paul Wouters <[e-mail]>]

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