Re: [IPsec] rfc8229bis missing advise on error handling in IKE_INIT

[Paul Wouters]

On Fri, 19 Mar 2021, Tommy Pauly wrote:


This implies that the new IKE_SA_INIT is a retry of the same IKE SA. Indeed, at 
least for our client, we don’t reset the SA values.


Yes, for a client sure. But for a server there is no guarantee the
client will come back. There is no point in keeping any state, until
now TCP came along.


  Similarly, when IKE_AUTH fails with NO_PROPOSAL_CHOSEN or
  AUTHENTICATION_FAILED, who is responsible for closing the TCP socket?
  The initiator or the responder?


8229 says:

   In order to close an IKE session, either the Initiator or Responder
   SHOULD gracefully tear down IKE SAs with DELETE payloads.  Once the
   SA has been deleted, the TCP Originator SHOULD close the TCP
   connection if it does not intend to use the connection for another
   IKE session to the TCP Responder.  If the connection is left idle and
   the TCP Responder needs to clean up resources, the TCP Responder MAY
   close the TCP connection.

This generally means: client goes first when closing TCP, but server should 
close if the client doesn’t in time.


That makes sense, but again it is different for the server case.
Normally, the server can delete all state after a NO_PROPOSAL_CHOSEN or
AUTHENTICATION_FAILED in IKE_AUTH, as there is no way to fix this failed
IKE SA negotiation - the client has to start from scratch.


Note also that a new TCP connection can always be used for an IKE SA from an 
old connection; that is allowed, so it’s possible that if
the server closes too early, the client will reopen with a new connection to 
send remaining messages.


Right. I guess we need to look at moving our TCP connections without
state into a separate corner, and either close them after a short while
or pick up a new IKE message on it from scratch.

But perhaps this is a useful clarification of the draft. That the
responder has to deal with a TCP session that has no IKE state.

In our case, this ended up in a crasher we are fixing :)

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [Lwip] draft-ietf-lwig-minimal-esp shepherd writeup

[Daniel Migault]

Hi,

To complement my previous response, I have added some text provided by Tero
to clarify the generation of SN from the time. We also added some
explanation around anti replay as well as some more context on the various
constraints different devices may have. We also add some clarification
about what dummy packet are as it seemed the reference to RFC4301 and
section was not sufficient.
On the other hand, I do not believe that is necessary to duplicate the
discussion around the choice of a specific transform and this discussion
should happen in the ESP cryptographic recommendations RFC8221. This also
avoids the document to be updated as crypto evolves and new transforms are
introduced.

The current version is available here:
https://github.com/mglt/draft-mglt-lwig-minimal-esp/blob/master/draft-ietf-lwig-minimal-esp.xml

Please find my response inline.

Yours,
Daniel



On Mon, Mar 22, 2021 at 12:45 PM Paul Wouters  wrote:

> On Mon, 22 Mar 2021, Tero Kivinen wrote:
>
> >> In general, this draft is very "wordy" because it is trying to steer
> >> itself around a lot of problems, without making firm decisions. But
> >> the point of an RFC is that it should make clear decisions that
> >> implementers can adopt clearly. As such, I'm not in favour of this
> >> draft. I believe I stated this before?
> >
> > This draft does not change anything in the ESP, it only gives
> > guidelines to the lightweight implementations so they can more easily
> > understand what kind of optimizations are allowed by standard ESP and
> > what benefits or concerns there might be from selecting them.
>
> I find the guidelines it gives unclear. This email has helped a lot and
> I would really like to see some of this text included in the draft.
>
> > Because it does not change ESP, it is not really IPsecME WG job. It is
> > similar than RFC7815 Minimal IKEv2 Initiator Implementation document,
> > which was also published from the LWIG WG and not from the IPsecME WG.
>
> Thanks for the process explanation. I'm okay continuing it this way.
>
> >> But it seems that although my comments caused the draft to be modified,
> >> it still allows non-random SPIs:
> >
> > This document cannot mandate that SPIs need to be random, as no such
> > requirement is in the standard ESP RFC.
>
> Interesting, I did not realise that. The draft could be clarified to
> simply state like, something like:
>
> RFC4303 states tat SPI's must be unique, but do not require to
> be random. Most implementations do use random SPIs but this
> might not be possible for constrained devices. These devices
> MAY use non-random SPIs.
>
> > But wasn't that attack you referenced, talking about IKE SPIs, not ESP
> > SPIs? At least that is what I remember about that attack...
>
> Yes, that is correct.
>
> > Also even IKE SPIs are not required to be random, they are just
> > required to be unique and non-zero.
>
> Perhaps we should update IKEv2 to SHOULD make them random :)
>
> >> If such a device cannot generate 4 random bytes, how is it performing a
> >> DiffieHellman key exchange? Or is it presumed that IKE is done
> >> elsewhere? In which case "elsewhere" can generate 4 random bytes.
> >
> > I do not think SPI issue is about generating it, but using it for each
> > incoming packet. If device has only support for 4 incoming SPIs, it
> > might just create SPIs using format 0x800x, where x is the index
> > in its SAD. Then getting address of SAD structure in memory could
> > simply be (SPI << (sad_table_shift)) + sad_table_start_address after
> > checking that (spi & 0xfffc) == 0x8000.
>
> Again the draft should be making this distinction clear. To me it seems
> to suggest that creating them randmonly was the problem being addressed.
>
> > Generation of the SPI is single operation, and as such not an issue.
> > Mapping SPI -> SAD entry must be done for every incoming packet, and
> > saving cycles from there might make difference.
> >
> >> What about IVs ? If you cannot generate 4 bytes of random, how it is
> >> going to generate the IVs required for ESP?
> >
> > Implicit Initialization Vector (IV) for Counter-Based Ciphers in
> > Encapsulating Security Payload (ESP), RFC 8750,
>
> That is only for the IV of AEAD algorithms. But the draft wiggles between
> discourages these because if you re-use the key along reboots without
> keeping
> state, you would re-use the same IV (counter). Later on in the document,
> and along with your explanation in this email, I understand that the
> time based counter addresses this. I think it should be made much more
> explicitly clear so that implementers know this.
>
>
> For AES-CBC, RFC 3602 states:
> https://tools.ietf.org/html/rfc3602#section-3
>
> The IV field MUST be the same size as the block size of the cipher
> algorithm being used.  The IV MUST be chosen at random, and MUST be
> unpredictable.
>
> So the draft basically states that for systems not able to generate a
> 

Re: [IPsec] [Lwip] draft-ietf-lwig-minimal-esp shepherd writeup

[Tero Kivinen]

Paul Wouters writes:
> Reading back now, I think with some clarifications added, I am okay
> with the document. I think the list of clarifications we now have is:

I think your list of things to add is mostly ok.

Note, that on some enviroments creating random numbers is possible,
but it takes time, and power to do so. For example it might be that
hardware random number generator is normally powered off, and is only
powered on during the IKE SA creation phase, and can only create
random numbers at very limited speed. It also might require some time
do self tests, calibration etc before it can be used, so using it per
packet might not be usable, while using it for generating randomness
during the initial phase is no problem.

Perhaps all this should be collected to one new section of the draft,
explaining that you do need proper randomness for Diffie-Hellman etc,
but for ESP you might not need proper random number generators.

> - A clear section on why AES-CBC/3DES-CBC cannot be used due to IV
>randomness limitations

That is not true. CBC mode requires IVs to be random and
unpredictable, but they do not really be true random, it is enough to
use pseudo random number generators for that. One way to get that is
to use fixed secret key (only known to the device, and no, do not use
key derived from the serial number or mac of the device or similar)
and encrypt the incrementing time with such key.

That should provide proper random IVs than can be used in CBC mode,
and which are unpredictable to everybody who does not know the key
used to generate them.

> - change "cryptographic suites" and "crypto-suites" to "cryptographic
>algorithms" to avoid TLS confusion

IKEv2 RFC7296 uses cryptograhic suites. RFC4303 or RFC4301 does not
use term suite at all. I would prefer keeping that same term than what
IKEv2 uses.

> - Remove reference to I-D.nikander-esp-beet-mode, with the text "not
>standarized yet". This draft has been abandoned in 13 years ago.

There has been some discussion every now and then to revive that
draft. There is some good properties in that especially for IoT
environments, as it does not send the extra inner IP header, when that
IP header can be constructed from the SAD.

Anyways that draft is clearly something that is not in scope for lwig,
but falls in the IPsecME scope, so removing that text now is probably
correct. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [Lwip] draft-ietf-lwig-minimal-esp shepherd writeup

[Daniel Migault]

Hi Paul,

A large part of your comments result from a confusion between the use of
SPI in IKE and ESP. This discussion  has already been set in [1]. Other
comments currently led to two minor updates in the document that have been
published here [2]. So far I believe your concerns have been addressed
unless I am misunderstood them.  Please find my responses in line.

Yours,
Daniel

[1] https://mailarchive.ietf.org/arch/msg/lwip/ygw567rdae2LLXoWTbdbXMejowI/
[2]
https://github.com/mglt/draft-mglt-lwig-minimal-esp/blob/master/draft-ietf-lwig-minimal-esp.xml

On Mon, Mar 22, 2021 at 12:12 AM Paul Wouters  wrote:

> On Sun, 21 Mar 2021, Daniel Migault wrote:
>
> (replying to some issues here, but also added a full review of the
> document)
>
> Side note: I am bit confused why this document would not be a document
> from the IPsecME WG ? I know we talked about this before? Did we decide
> against adoption at IPsecME ? Can the authors, WG chairs of IPsecME or
> the responsible AD shed some light on the history here?
>
> 
The document minimal esp complements minimal IKEv2 RFC 7815 that was
adopted in LWIG and the goal of the document seems in scope with LWIG, that
is building minimal interoperable IP capable devices for the most
constrained environment.  As the matter (ESP) might involve the IPsec
community we always cced the ipsecme as well as by making presentations
during ipsecme sessions.
Maybe you could clarify what in particular you find confusing.


In general, this draft is very "wordy" because it is trying to steer
> itself around a lot of problems, without making firm decisions.

But the point of an RFC is that it should make clear decisions that
> implementers can adopt clearly.

 
The scope of the document is to provide guidance for implementers on
minimal implementations while remaining interoperable. The techniques an
implementer will choose depend on its constraints and environment and there
is not an intention to favor one technique over the others.
This document and describes how an implementer may achieve a minimal
implementation while remaining interoperable. Decision of what to implement
is let to the implementer.



> As such, I'm not in favour of this
> draft. I believe I stated this before?
>
> > [1]
> https://github.com/mglt/draft-mglt-lwig-minimal-esp/commit/47f1351b1928ba687af18e75e253e98720448e8e
> > On Sat, Mar 20, 2021 at 5:12 AM Mohit Sethi M  40ericsson@dmarc.ietf.org> wrote:
> >   I am now preparing the shepherd writeup for
> draft-ietf-lwig-minimal-esp.
> >   I wanted to clarify and double check a few things:
> >
> >   - If the SPI is not random and is chosen by some application
> specific
> >   method -> it can reveal the application using ESP.
> >
> > 
> > It is correct that the use of non random SPI may have some privacy
> impacts and one of these impacts is that in some cases, a SPI may be used
> to track an application. Note that our intention was to make it
> > clear that when SPI are non randomly generated, there are some privacy
> implications to consider as well as that randomly generated SPI is
> preferred.
>
> At the time I also mentioned one attack against IKE that was twarted by
> having 4 random bytes as SPI. It remains dangerous to change this
> property of ESP, and I recommended to not do that.
>
> https://access.redhat.com/blogs/product-security/posts/sloth
>
> But it seems that although my comments caused the draft to be modified,
> it still allows non-random SPIs:
>
> However, for some constrained nodes, generating and handling 32 bit
> random SPI may consume too much resource, in which case SPI can be
> generated using predictable functions or end up in a using a subset
> of the possible values for SPI.  In fact, the SPI does not
> necessarily need to be randomly generated.  A node provisioned with
> keys by a third party - e.g. that does not generate them - and that
> uses a transform that does not needs random data may not have such
> random generators.  However, nonrandom SPI and restricting their
> possible values MAY lead to privacy and security concerns.  As a
> result, this alternative should be considered for devices that would
> be strongly impacted by the generation of a random SPI and after
> understanding the privacy and security impact of generating nonrandom
> SPI.
>
> So I feel I raised a security issue, and the text just copied my concern
> but still basically states implementations MAY do this. I believe this
> is wrong.
>


The security concerned you raised is irrelevant here. The SLOTH attack only
concerns SIGMA protocols and ESP does not involve any SIGMA protocols.
This concern has been addressed and you agreed in the following words [1]:
"""

As Tero pointed out to me just now, those were IKE SPI's and not ESP
SPI's to I guess there is no security issue here :)

"""
[1] https://mailarchive.ietf.org/arch/msg/lwip/ygw567rdae2LLXoWTbdbXMejowI/



> > Note that the draft 

Re: [IPsec] [Lwip] draft-ietf-lwig-minimal-esp shepherd writeup

[Paul Wouters]

On Mon, 22 Mar 2021, Tero Kivinen wrote:


In general, this draft is very "wordy" because it is trying to steer
itself around a lot of problems, without making firm decisions. But
the point of an RFC is that it should make clear decisions that
implementers can adopt clearly. As such, I'm not in favour of this
draft. I believe I stated this before?


This draft does not change anything in the ESP, it only gives
guidelines to the lightweight implementations so they can more easily
understand what kind of optimizations are allowed by standard ESP and
what benefits or concerns there might be from selecting them.


I find the guidelines it gives unclear. This email has helped a lot and
I would really like to see some of this text included in the draft.


Because it does not change ESP, it is not really IPsecME WG job. It is
similar than RFC7815 Minimal IKEv2 Initiator Implementation document,
which was also published from the LWIG WG and not from the IPsecME WG.


Thanks for the process explanation. I'm okay continuing it this way.


But it seems that although my comments caused the draft to be modified,
it still allows non-random SPIs:


This document cannot mandate that SPIs need to be random, as no such
requirement is in the standard ESP RFC.


Interesting, I did not realise that. The draft could be clarified to
simply state like, something like:

RFC4303 states tat SPI's must be unique, but do not require to
be random. Most implementations do use random SPIs but this
might not be possible for constrained devices. These devices
MAY use non-random SPIs.


But wasn't that attack you referenced, talking about IKE SPIs, not ESP
SPIs? At least that is what I remember about that attack...


Yes, that is correct.


Also even IKE SPIs are not required to be random, they are just
required to be unique and non-zero.


Perhaps we should update IKEv2 to SHOULD make them random :)


If such a device cannot generate 4 random bytes, how is it performing a
DiffieHellman key exchange? Or is it presumed that IKE is done
elsewhere? In which case "elsewhere" can generate 4 random bytes.


I do not think SPI issue is about generating it, but using it for each
incoming packet. If device has only support for 4 incoming SPIs, it
might just create SPIs using format 0x800x, where x is the index
in its SAD. Then getting address of SAD structure in memory could
simply be (SPI << (sad_table_shift)) + sad_table_start_address after
checking that (spi & 0xfffc) == 0x8000.


Again the draft should be making this distinction clear. To me it seems
to suggest that creating them randmonly was the problem being addressed.


Generation of the SPI is single operation, and as such not an issue.
Mapping SPI -> SAD entry must be done for every incoming packet, and
saving cycles from there might make difference.


What about IVs ? If you cannot generate 4 bytes of random, how it is
going to generate the IVs required for ESP?


Implicit Initialization Vector (IV) for Counter-Based Ciphers in
Encapsulating Security Payload (ESP), RFC 8750,


That is only for the IV of AEAD algorithms. But the draft wiggles between
discourages these because if you re-use the key along reboots without keeping
state, you would re-use the same IV (counter). Later on in the document,
and along with your explanation in this email, I understand that the
time based counter addresses this. I think it should be made much more
explicitly clear so that implementers know this.


For AES-CBC, RFC 3602 states: https://tools.ietf.org/html/rfc3602#section-3

The IV field MUST be the same size as the block size of the cipher
algorithm being used.  The IV MUST be chosen at random, and MUST be
unpredictable.

So the draft basically states that for systems not able to generate a
random bytes, that it cannot use AES-CBC. It should state this
explictly.


IKE SPI or ESP SPI? My understanding those attacks were against IKE,
not against ESP.

And if what you are saying is true, then we as an IPsecME needs to
start making modification to the ESP to actually require the SPI to be
random. Currently it does not need to be random, just unique from the
local point of view.


Based on the attack, this would only be needed for IKE, not ESP. But for
implementations this draft targets, that would be a similar
insurmountable problem? Again, it would be useful to explain why pure
random is harder to do then using something time based.


The secion on Sequence Numbers concerns me too, and for the same reasons
as above. If you cannot keep a sequence number as state, you cannot do
any AEAD encryption. I believe it is a bad idea to still write
specifications today that require non-AEAD algorithms. Once you can do
it for AEAD, then you can do it for SN too (and using the other draft
that specified re-using the SN for one of these for other saves you
those bytes once).


You can use AEAD encryption with sequence numbers generated by time

Re: [IPsec] [Lwip] draft-ietf-lwig-minimal-esp shepherd writeup

[Tero Kivinen]

Paul Wouters writes:
> On Sun, 21 Mar 2021, Daniel Migault wrote:
> 
> (replying to some issues here, but also added a full review of the document)
> 
> Side note: I am bit confused why this document would not be a document
> from the IPsecME WG ? I know we talked about this before? Did we decide
> against adoption at IPsecME ? Can the authors, WG chairs of IPsecME or
> the responsible AD shed some light on the history here?
> 
> In general, this draft is very "wordy" because it is trying to steer
> itself around a lot of problems, without making firm decisions. But
> the point of an RFC is that it should make clear decisions that
> implementers can adopt clearly. As such, I'm not in favour of this
> draft. I believe I stated this before?

This draft does not change anything in the ESP, it only gives
guidelines to the lightweight implementations so they can more easily
understand what kind of optimizations are allowed by standard ESP and
what benefits or concerns there might be from selecting them.

Because it does not change ESP, it is not really IPsecME WG job. It is
similar than RFC7815 Minimal IKEv2 Initiator Implementation document,
which was also published from the LWIG WG and not from the IPsecME WG. 

> But it seems that although my comments caused the draft to be modified,
> it still allows non-random SPIs:

This document cannot mandate that SPIs need to be random, as no such
requirement is in the standard ESP RFC. Requiring SPIs to be random
would be a change from RFC4303, and as such cannot be done in this
document.

For example RFC4301 defines SPI as follows in its Appendix A:
Glossary:

--
   Security Parameters Index (SPI)
  An arbitrary 32-bit value that is used by a receiver to identify
  the SA to which an incoming packet should be bound.  For a unicast
  SA, the SPI can be used by itself to specify an SA, or it may be
  used in conjunction with the IPsec protocol type.  Additional IP
  address information is used to identify multicast SAs.  The SPI is
  carried in AH and ESP protocols to enable the receiving system to
  select the SA under which a received packet will be processed.  An
  SPI has only local significance, as defined by the creator of the
  SA (usually the receiver of the packet carrying the SPI); thus an
  SPI is generally viewed as an opaque bit string.  However, the
  creator of an SA may choose to interpret the bits in an SPI to
  facilitate local processing.
--

>From the last sentence it is clear that SPI can also be non-random.
You can for example take last 8 bits of the SPI and use that as CPU
identifier, and use next 16-bits before that as index to the SPI table
on that CPU specific SPI table, and use 0xff as first 8-bits just so
you never end up having any reserved numbers for your SPI, i.e., have
SPI as 0xffcc, where  is index and cc is cpu id. 

> So I feel I raised a security issue, and the text just copied my concern
> but still basically states implementations MAY do this. I believe this
> is wrong.

But wasn't that attack you referenced, talking about IKE SPIs, not ESP
SPIs? At least that is what I remember about that attack...

Also even IKE SPIs are not required to be random, they are just
required to be unique and non-zero.

> If such a device cannot generate 4 random bytes, how is it performing a
> DiffieHellman key exchange? Or is it presumed that IKE is done
> elsewhere? In which case "elsewhere" can generate 4 random bytes.

I do not think SPI issue is about generating it, but using it for each
incoming packet. If device has only support for 4 incoming SPIs, it
might just create SPIs using format 0x800x, where x is the index
in its SAD. Then getting address of SAD structure in memory could
simply be (SPI << (sad_table_shift)) + sad_table_start_address after
checking that (spi & 0xfffc) == 0x8000.

Generation of the SPI is single operation, and as such not an issue.
Mapping SPI -> SAD entry must be done for every incoming packet, and
saving cycles from there might make difference.

> What about IVs ? If you cannot generate 4 bytes of random, how it is
> going to generate the IVs required for ESP?

Implicit Initialization Vector (IV) for Counter-Based Ciphers in
Encapsulating Security Payload (ESP), RFC 8750,

> > In fact, the SPI does not necessarily need to be randomly generated.
> 
> Yes it is does, see the above link on an attack against IKE where the
> randomized SPI made offline attacks impossible and online attacks
> impractical.

IKE SPI or ESP SPI? My understanding those attacks were against IKE,
not against ESP.

And if what you are saying is true, then we as an IPsecME needs to
start making modification to the ESP to actually require the SPI to be
random. Currently it does not need to be random, just unique from the
local point of view.

> 

Re: [IPsec] [Lwip] draft-ietf-lwig-minimal-esp shepherd writeup

[Paul Wouters]

On Mon, 22 Mar 2021, Mohit Sethi M wrote:


Adding Ben (IPsecME AD) and Erik (LWIG AD) to the CC list for an early heads up.

Thanks for reviewing the document. I'll let the authors provide answers to your 
review.

On the procedural side of things: this document is within the LWIG charter 
(https://datatracker.ietf.org/wg/lwig/charter/) and follows the path taken by 
Minimal IKEv2 which was also completed in LWIG as RFC
7815 (https://datatracker.ietf.org/doc/rfc7815/).

During the call for adoption, there was a general consensus to proceed in LWIG 
while keeping close contacts with IPsecME (as well as an agreement to issue a 
joint last call). Tero
(https://mailarchive.ietf.org/arch/msg/lwip/Shf2oUKvtIsb0uzY2zRwuBurm58/), 
Valery 
(https://mailarchive.ietf.org/arch/msg/lwip/p1i4hZBjn7PD3ksS9kh8C0ouUOU/) and 
Scott
(https://mailarchive.ietf.org/arch/msg/lwip/dF3eZXG8GTV-o7aH4BnFk2zlR6c/) for 
example provided reviews of the draft.


Thanks for the write up here.


I think your comments during the adoption 
(https://mailarchive.ietf.org/arch/msg/lwip/xDcICiuALZ2ExF3qwRCnhCQC3A0/) did 
not argue moving this draft to IPsecME (unless I missed something):

If the document is defining a minimum/battery optimized ESP
configuartion, I have no problems with it and I will review further
text and welcome adoption. If it makes changes to the ESP protocol,
then I think there should be more discussion before adoption.

Paul


I said that, but I think I am seeing changes to the ESP algorithm that
basically constitute a change to the ESP protocol. Furthermore, a bunch
of advise negating the advise in RFC 8223. And I still haven't heard
a justfication of some issues I raised either. Such as the doing a
full IKE exchange yet not being able to generate 4 bytes of random?


That being said, I am not fundamentally opposed to moving this document to 
IPsecME. However, it is important to consider that the document has already had 
a relatively long lifecycle in LWIG.


After you references I had given feedback, I went back and read that
message. I totally forgot I did that two years ago. But all the issues
I raised back then are still there unresolved.

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [Lwip] draft-ietf-lwig-minimal-esp shepherd writeup

[Mohit Sethi M]

Hi Paul,

Adding Ben (IPsecME AD) and Erik (LWIG AD) to the CC list for an early heads up.

Thanks for reviewing the document. I'll let the authors provide answers to your 
review.

On the procedural side of things: this document is within the LWIG charter 
(https://datatracker.ietf.org/wg/lwig/charter/) and follows the path taken by 
Minimal IKEv2 which was also completed in LWIG as RFC 7815 
(https://datatracker.ietf.org/doc/rfc7815/).

During the call for adoption, there was a general consensus to proceed in LWIG 
while keeping close contacts with IPsecME (as well as an agreement to issue a 
joint last call). Tero 
(https://mailarchive.ietf.org/arch/msg/lwip/Shf2oUKvtIsb0uzY2zRwuBurm58/), 
Valery 
(https://mailarchive.ietf.org/arch/msg/lwip/p1i4hZBjn7PD3ksS9kh8C0ouUOU/) and 
Scott (https://mailarchive.ietf.org/arch/msg/lwip/dF3eZXG8GTV-o7aH4BnFk2zlR6c/) 
for example provided reviews of the draft.

I think your comments during the adoption 
(https://mailarchive.ietf.org/arch/msg/lwip/xDcICiuALZ2ExF3qwRCnhCQC3A0/) did 
not argue moving this draft to IPsecME (unless I missed something):

If the document is defining a minimum/battery optimized ESP
configuartion, I have no problems with it and I will review further
text and welcome adoption. If it makes changes to the ESP protocol,
then I think there should be more discussion before adoption.

Paul

That being said, I am not fundamentally opposed to moving this document to 
IPsecME. However, it is important to consider that the document has already had 
a relatively long lifecycle in LWIG.

--Mohit

On 3/22/21 6:12 AM, Paul Wouters wrote:
On Sun, 21 Mar 2021, Daniel Migault wrote:

(replying to some issues here, but also added a full review of the document)

Side note: I am bit confused why this document would not be a document
from the IPsecME WG ? I know we talked about this before? Did we decide
against adoption at IPsecME ? Can the authors, WG chairs of IPsecME or
the responsible AD shed some light on the history here?

In general, this draft is very "wordy" because it is trying to steer
itself around a lot of problems, without making firm decisions. But
the point of an RFC is that it should make clear decisions that
implementers can adopt clearly. As such, I'm not in favour of this
draft. I believe I stated this before?

[1] 
https://protect2.fireeye.com/v1/url?k=267ff37b-79e4ca56-267fb3e0-8692dc8284cb-4b11e1d62003bf58=1=de278ec7-abe4-4a5c-bad8-76ad8f57cf87=https%3A%2F%2Fgithub.com%2Fmglt%2Fdraft-mglt-lwig-minimal-esp%2Fcommit%2F47f1351b1928ba687af18e75e253e98720448e8e
On Sat, Mar 20, 2021 at 5:12 AM Mohit Sethi M 

 wrote:
  I am now preparing the shepherd writeup for draft-ietf-lwig-minimal-esp.
  I wanted to clarify and double check a few things:

  - If the SPI is not random and is chosen by some application specific
  method -> it can reveal the application using ESP.


It is correct that the use of non random SPI may have some privacy impacts and 
one of these impacts is that in some cases, a SPI may be used to track an 
application. Note that our intention was to make it
clear that when SPI are non randomly generated, there are some privacy 
implications to consider as well as that randomly generated SPI is preferred.

At the time I also mentioned one attack against IKE that was twarted by
having 4 random bytes as SPI. It remains dangerous to change this
property of ESP, and I recommended to not do that.

https://access.redhat.com/blogs/product-security/posts/sloth

But it seems that although my comments caused the draft to be modified,
it still allows non-random SPIs:

   However, for some constrained nodes, generating and handling 32 bit
   random SPI may consume too much resource, in which case SPI can be
   generated using predictable functions or end up in a using a subset
   of the possible values for SPI.  In fact, the SPI does not
   necessarily need to be randomly generated.  A node provisioned with
   keys by a third party - e.g. that does not generate them - and that
   uses a transform that does not needs random data may not have such
   random generators.  However, nonrandom SPI and restricting their
   possible values MAY lead to privacy and security concerns.  As a
   result, this alternative should be considered for devices that would
   be strongly impacted by the generation of a random SPI and after
   understanding the privacy and security impact of generating nonrandom
   SPI.

So I feel I raised a security issue, and the text just copied my concern
but still basically states implementations MAY do this. I believe this
is wrong.

Note that the draft defined one (common way) to generate the SPI value that is 
using a random generator to generate this SPI value. All other means fall into 
the category of using deterministic functions.
This does not necessarily mean that a fix of predefined SPI will necessarily be 
used. This includes for example the fact that