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

[Daniel Migault <[e-mail]>]

Hi Paul,

Thanks for the response. Please see my responses inline.

Yours,
Daniel

On Tue, Jul 19, 2022 at 11:47 AM Paul Wouters <[e-mail]> wrote:

> 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 device could be provisioned with a master secret from which keys are
derived. It uses one byte of the SPI to indicate which key is in use. The
other peer is provisioned the same way and can generate the appropriate
key. This rekey improves the use case of a device (without IKEv2) only
provisioned with a single key while avoiding the management of multiple SAs
- especially when the rekey occurs. Typically a rekey performed by IKE
creates a new SA and deletes the previous one.

Let me know if the proposed text is clearer.

OLD
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.

NEW
This enables indicating both the SA and the key being used for the packet.
When the last byte of the SPI changes, the device generates or retrieves
the corresponding key and assigns it to the SA.


> >       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".
>
> I added your text while keeping the description of the problem.


> > 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".
>
>
The document is structured by listing all field of ESP, so I prefer to keep
"Next header" in the title. While dummy packets are the main focus we also
describe the field with alternative uses like beet mode. I think it would
be strange to only have dummy packet in the title.

> Paul



-- 
Daniel Migault
Ericsson