Minimal IP Encapsulating Security Payload (ESP)
draft-ietf-lwig-minimal-esp-12

[Ballot comment]
Thanks for changes to the document.

My DISCUSS items were addressed enough for me to not block the document for publication.


Old DISCUSS items:

[1]

Section 2:

It suggests a partial SPI match can be used, based on the assumption that
the SPI number is known to have mostly zeros because the device only uses
a hardcoded limited set (eg 257 to 260). While this is true for the outbound
SPI, this may not be true for the inbound SPI, especially if the peer is not
a "minimal ESP" device but a regular multipurpose OS. I think some clarification
is needed for this minimum implementation optimization.

[2]

Section 2.1:

      SPI that are not randomly generated over 32 bits may lead to privacy
      and security concerns.

The "may lead to security concerns" would be something that at the very least needs
to be understood and specified in the Security Considerations section. If it is too
difficult to determine the concerns, perhaps this optimization should be removed from
the draft.

      As a result, the use of alternative designs requires careful security
      and privacy reviews.

If it is known this proposal requires careful security reviews, were these done? If
so, why not replace this warning of danger with the actual output of those reviews?
If reviews were not done, it would imply this document hasn't fully worked out its
Security Considerations.

[3]

      SPI can typically be used to implement a key update

What is a "key update" in this context? It seems this section is suggesting to use
part of the SPI octet space to signal things to another part of the code on the device?
If so, would that code part then clear out those overloaded SPI octets or would they go
(unencrypted!) over the network for everyone to see?

[4]

      While the use of randomly generated SPIs may reduce the leakage or
      privacy of security related information by ESP itself, these
      information may also be leaked otherwise.

This is not a strong argument. This sentence and the entire paragraph really seem to
want to say something like "if you can see the network packets, the information
leak would already be present by seeing the encrypted traffic, irrespective of
whether the SPI is truly random or selected in a way that identifies the manufacturer"

[5]

      The security of all data
      protected under a given key decreases slightly with each message

I do not know of a generic claim like this for ESP. Can a reference be provided?
In general, rekeying is done to avoid decrypting previous traffic in case of a key compromise.
Or perhaps you mean the limits of algorithms like AES_CBC (or 3DES) with respect to
birthday and collision attacks? eg the commonly used maximum of 2^32-1 crypto operations
(which is not the same as maximum packets)

In these cases, the SN is only relevant for very high speed links, eg gbps and would never
apply to an IoT device that requires minimal ESP.

[6]

As noted in the TSVART review:

      Also, for devices that spend significant time sleeping, the SN
      would jump hugely on first waking. That shouldn't require any
      larger window (unless a stale packet from prior to the sleep was
      only released after a new packet on waking). But the receiver
      would need to be able to somehow detect massive jumps in the high
      order bits that are not communicated in the SN field.

Perhaps the document can add more specific detail on how to use the commonly
implemented time values into valid SNs that avoid ESN issues ?


[7]

      so the constrained device may not proceed to such checks

The language issue here inverts the meaning. What is meant is "so the constrained device
may omit such checks"

[8]

      TFC has not yet being widely adopted for standard ESP traffic.

It is widely implemented (eg in Linux). I agree that using it seems rare.
I am not convinced the reason for this is as is written. The issue I think
more relates to deciding to what size to pad. The easiest is to use the MTU,
but due to various encapsulation techniques (ESPinUDP, PPP-OE) it is not always
clear what the MTU of the IPsec link is. And path MTU discovery with IPsec does
not really work in practice.

But if the application/device tends to send packets between 1 and say 125 bytes,
it could always pad to 125 to not leak any information by packet size. The question
on when to do this or not really depends on the traffic being protected. And if this
the case, then it might be best to let the IKEv2 negotiation determine whether or not
to use this - just like regular use of TFC.

Regardless, TFC is optional and a minimum implementation can just omit it. Since
this document would also be combined with efforts reducing sending bytes to
preserve energy, it would make sense to avoid using TFC padding. Especially for sensors
that for example just always send a one byte temperature value to begin with.

      Such information could be used by the attacker in case a vulnerability is
      disclosed on the specific device.

I don't think "vulnerability" here is the issue. It could lead to exposing the size
of the original packet being protected by IPsec, which could (or could not) leak
information to an observer on the network.

[9]

      a minimal ESP implementation may not generate such dummy packet.

I think what is meant is "MUST NOT generate".

[10]

The Next Header Section is better named Dummy Packet. While it discusses the mandatory
Next Header field, it really only states not to send Dummy Packets. But it almost reads
as if the Next Header can be ignored or omitted.

[11]

      4.  Avoid Padding by sending payload data which are aligned to
          the cipher block length - 2 for the ESP trailer.

Isn't this advise just moving the padding from the IPsec layer to the application
layer? Eg the packet size or energy use would not be different if one implements
this advise?

[12]

Would it be useful to be able to signal a "mininum ESP" via IKEv2? I can imagine a simple
Notify could be used to signal this. A peer receiving this could then ensure it is
behaving in a "minimum ESP" compatible way even if it is a multi-purpose OS.

Comments:

There is a bit excessive and inconsistent linking to RFC 4303 throughout
the document. I think on first use of ESP the RFC can be referenced, but
further the document can just talk about ESP without keeping links to RFC 4303.
(I also thought there should not be any links in the abstract?)

The document should maybe mention IPsec v3 is meant for "ESP". IPsec v3 is a superset
of IPsec v2. There is no compatibility issue because the "new" things in v3 are
all negotiated via IKE.

I don't understand "a form of partial sequence integrity", as integrity
is a boolean - it passes or fails. I don't understand "partial"

"it becomes crucial" is a bit weak. I would say it must be guaranteed
that ESP on IoT remains interoperable with currently deployed ESP.

      This may raise some privacy issues as an
      observer is likely to be able to determine the constrained devices of
      the network.

This text might be better placed in a Privacy Considerations section.

The term "traffic shaping" is used in the document to refer to traffic being
padded (padding or TFC). Perhaps my personal exposure to Linux has caused me
to think of "traffic shaping" to mean to control the speed or flow of traffic,
and not meaning "modifying traffic size".

[Ballot discuss]
** Section 5.  The paragraph starting with “As the generation of dummy packets …” would benefit from refinement.  It starts with saying dummy packets “may be avoided”, but the second half of the paragraph argues the opposite.  The use cases of constrained devices concerned about device lifetimes (first half of the paragraph) doesn’t seem mutually exclusive from those with dedicated applications (second half).  I recommend being cleared on the assumptions guiding the use of dummy packets.

[Ballot comment]
Thank you to David Mandelberg for the SECDIR review.

I support Paul Wouter’s DISCUSS position.

** IDnits reports:

  == Unused Reference: 'RFC2119' is defined on line 553, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC8174' is defined on line 581, but no explicit
    reference was found in the text

** Please add a privacy consideration section (or merge it into the Security Considerations) to say that the practices suggested in Section 2.1 will reduce privacy/security by enabling device fingerprinting.

** Section 2.
  For nodes supporting only unicast communications, this document
  recommends to index SA with the SPI only. 

I don’t follow how this is new guidance.  Section 4.1 of RFC4301 only seems to already suggest that:

For an SA used to carry unicast traffic, the Security Parameters
  Index (SPI) by itself suffices to specify an SA.  ... However, as a local matter, an implementation may choose
  to use the SPI in conjunction with the IPsec protocol type (AH or
  ESP) for SA identification. 

** Section 2

  Typically, temperature sensors, wind sensors, used outdoors may not
  leak privacy sensitive information and most of its traffic is
  expected to be outbound traffic.  When used indoors, a sensor that
  reports every minute an encrypted status of the door (closed or
  opened) may leak truly little privacy sensitive information outside
  the local network.  In both cases, if the state of the sensor doesn't
  leak privacy info, a randomized SPI is not necessary.

Is this temperature/wind sensor example assuming that potentially leaking model and version information is not privacy sensitive (as established as possible in the previous paragraph)?

Is the door sensor example assuming that it is communicating on a local network?  This is a design decision that this class of sensor could never be integrated otherwise?

** Section 3.
  For inbound traffic, this document recommends that any receiver
  provides anti-replay protection,

What is the intent of this guidance – is it that “this document recommends that all receivers provide anti-replay protection”?  I’m having difficulty parsing the “any receiver”.

** Section 4.  Per the paragraph starting with “As a result, TFC cannot be enabled …”, I don’t understand why this text is needed.  The previous paragraph established that TFC is not recommended for this profile.  Why comment on an extension which is not part of the profile?

** Section 4.  Per the paragraph starting with “some constrained nodes …”, is this paragraph also needed?  What minimal ESP guidance is the implementer intended to take from this text?

** Section 7.

  This section lists some of the criteria that may be considered. 

Considered in support of what decision?

** Section 7.
  As a result, the list is provided as informational:

How should the reader use an informational list in an information document which doesn’t use any RFC2119 normative language?

** Section 7.
    In the latter case, authenticated
    encryption must always be considered [RFC8221].

What does it mean to “consider” authenticated encryption?  Should it be used as a first choice, unless use is not possible?

** Section 7.
      When the key is likely to be re-used
      across reboots, this document recommends to consider algorithms
      that are nonce misuse resistant such as,

What does it mean to “recommend to consider”?

** Section 7.  Bullet 3, Interoperability.  The guidance being given to implementers isn’t clear to me.

Editorial
-- Section 3.  Typo.  s/know whereas the received/know whether the received/

-- Section 3. Editorial. s/sending a temperature/sending a temperature measurement/ 

-- Section 3.  s/sending a temperature/sending a temperature measurement/

-- Section 4.  Typo. s/TFC has not yet being/TFC has not been/

-- Section 5.  Typo. s/More especially, in constrained /Specifically, in a constrained/

-- Section 5.  Typo. s/and so may be avoided/a should be avoided/.

-- Section 7.  s/overtime/over time/

-- Section 7.  Typo.  s/not be known vulnerable or weak/must not use ciphers known to be vulnerable or weak/

-- Section 9.  Editorial.  s/for each field/for each ESP field/.

[Ballot discuss]
I must apologize first to the authors. Many months ago I promised to send
a diff with language improvements, and I did not do so. Unfortunately, I do
think the document needs this and the amount is too much to leave on the RFC
Editor. I will send a separate diff for language improvements to the authors
and not further comment on language in my ballot here.

[1]

Section 2:

It suggests a partial SPI match can be used, based on the assumption that
the SPI number is known to have mostly zeros because the device only uses
a hardcoded limited set (eg 257 to 260). While this is true for the outbound
SPI, this may not be true for the inbound SPI, especially if the peer is not
a "minimal ESP" device but a regular multipurpose OS. I think some clarification
is needed for this minimum implementation optimization.

[2]

Section 2.1:

      SPI that are not randomly generated over 32 bits may lead to privacy
      and security concerns.

The "may lead to security concerns" would be something that at the very least needs
to be understood and specified in the Security Considerations section. If it is too
difficult to determine the concerns, perhaps this optimization should be removed from
the draft.

      As a result, the use of alternative designs requires careful security
      and privacy reviews.

If it is known this proposal requires careful security reviews, were these done? If
so, why not replace this warning of danger with the actual output of those reviews?
If reviews were not done, it would imply this document hasn't fully worked out its
Security Considerations.

[3]

      SPI can typically be used to implement a key update

What is a "key update" in this context? It seems this section is suggesting to use
part of the SPI octet space to signal things to another part of the code on the device?
If so, would that code part then clear out those overloaded SPI octets or would they go
(unencrypted!) over the network for everyone to see?

[4]

      While the use of randomly generated SPIs may reduce the leakage or
      privacy of security related information by ESP itself, these
      information may also be leaked otherwise.

This is not a strong argument. This sentence and the entire paragraph really seem to
want to say something like "if you can see the network packets, the information
leak would already be present by seeing the encrypted traffic, irrespective of
whether the SPI is truly random or selected in a way that identifies the manufacturer"

[5]

      The security of all data
      protected under a given key decreases slightly with each message

I do not know of a generic claim like this for ESP. Can a reference be provided?
In general, rekeying is done to avoid decrypting previous traffic in case of a key compromise.
Or perhaps you mean the limits of algorithms like AES_CBC (or 3DES) with respect to
birthday and collision attacks? eg the commonly used maximum of 2^32-1 crypto operations
(which is not the same as maximum packets)

In these cases, the SN is only relevant for very high speed links, eg gbps and would never
apply to an IoT device that requires minimal ESP.

[6]

As noted in the TSVART review:

      Also, for devices that spend significant time sleeping, the SN
      would jump hugely on first waking. That shouldn't require any
      larger window (unless a stale packet from prior to the sleep was
      only released after a new packet on waking). But the receiver
      would need to be able to somehow detect massive jumps in the high
      order bits that are not communicated in the SN field.

Perhaps the document can add more specific detail on how to use the commonly
implemented time values into valid SNs that avoid ESN issues ?


[7]

      so the constrained device may not proceed to such checks

The language issue here inverts the meaning. What is meant is "so the constrained device
may omit such checks"

[8]

      TFC has not yet being widely adopted for standard ESP traffic.

It is widely implemented (eg in Linux). I agree that using it seems rare.
I am not convinced the reason for this is as is written. The issue I think
more relates to deciding to what size to pad. The easiest is to use the MTU,
but due to various encapsulation techniques (ESPinUDP, PPP-OE) it is not always
clear what the MTU of the IPsec link is. And path MTU discovery with IPsec does
not really work in practice.

But if the application/device tends to send packets between 1 and say 125 bytes,
it could always pad to 125 to not leak any information by packet size. The question
on when to do this or not really depends on the traffic being protected. And if this
the case, then it might be best to let the IKEv2 negotiation determine whether or not
to use this - just like regular use of TFC.

Regardless, TFC is optional and a minimum implementation can just omit it. Since
this document would also be combined with efforts reducing sending bytes to
preserve energy, it would make sense to avoid using TFC padding. Especially for sensors
that for example just always send a one byte temperature value to begin with.

      Such information could be used by the attacker in case a vulnerability is
      disclosed on the specific device.

I don't think "vulnerability" here is the issue. It could lead to exposing the size
of the original packet being protected by IPsec, which could (or could not) leak
information to an observer on the network.

[9]

      a minimal ESP implementation may not generate such dummy packet.

I think what is meant is "MUST NOT generate".

[10]

The Next Header Section is better named Dummy Packet. While it discusses the mandatory
Next Header field, it really only states not to send Dummy Packets. But it almost reads
as if the Next Header can be ignored or omitted.

[11]

      4.  Avoid Padding by sending payload data which are aligned to
          the cipher block length - 2 for the ESP trailer.

Isn't this advise just moving the padding from the IPsec layer to the application
layer? Eg the packet size or energy use would not be different if one implements
this advise?

[12]

Would it be useful to be able to signal a "mininum ESP" via IKEv2? I can imagine a simple
Notify could be used to signal this. A peer receiving this could then ensure it is
behaving in a "minimum ESP" compatible way even if it is a multi-purpose OS.

[Ballot comment]

There is a bit excessive and inconsistent linking to RFC 4303 throughout
the document. I think on first use of ESP the RFC can be referenced, but
further the document can just talk about ESP without keeping links to RFC 4303.
(I also thought there should not be any links in the abstract?)

The document should maybe mention IPsec v3 is meant for "ESP". IPsec v3 is a superset
of IPsec v2. There is no compatibility issue because the "new" things in v3 are
all negotiated via IKE.

I don't understand "a form of partial sequence integrity", as integrity
is a boolean - it passes or fails. I don't understand "partial"

"it becomes crucial" is a bit weak. I would say it must be guaranteed
that ESP on IoT remains interoperable with currently deployed ESP.

      This may raise some privacy issues as an
      observer is likely to be able to determine the constrained devices of
      the network.

This text might be better placed in a Privacy Considerations section.

The term "traffic shaping" is used in the document to refer to traffic being
padded (padding or TFC). Perhaps my personal exposure to Linux has caused me
to think of "traffic shaping" to mean to control the speed or flow of traffic,
and not meaning "modifying traffic size".

[Ballot comment]
Section 2. , paragraph 6, comment:
>    [RFC4303] does not require the SPI to be randomly generated over 32
>    bits.  However, this is the recommended way to generate SPIs as it
>    provides some privacy benefits and avoids, for example, correlation
>    between ESP communications.  To randomly generate a 32 bit SPI, the
>    node generates a random 32 bit valueand checks it does not fall in
>    the 0-255 range.  If the SPI has an acceptable value, it is used to
>    index the inbound session, otherwise the SPI is re-generated until an
>    acceptable value is found.

Wouldn't it be simpler to compute a 24-bit random value and left-shift it by
eight? Or left-shift the 32-bit value; both remove the need to check.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "dummy"; alternatives might be "placeholder", "sample", "stand-in",
  "substitute".

Thanks to Roni Even for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/W3R6WdPRLgAuvMIJYWnld5uaCmU).

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2. , paragraph 6, nit:
-    node generates a random 32 bit valueand checks it does not fall in
+    node generates a random 32 bit value and checks it does not fall in
+                                        +

Section 3. , paragraph 6, nit:
-    are no requirements to implement an anti-replay protection mechanism
-    implemented by IPsec.  Similarly to the SN the implementation of anti
-  -----------------------
+    are no requirements to implement an anti-replay protection mechanism.
+                                                                        +

Section 4. , paragraph 4, nit:
-    would typically be the case when the Data Payload is of fix size.
+    would typically be the case when the Data Payload is of fixed size.
+                                                              ++

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

Uncited references: [RFC2119] and [RFC8174].

Section 1. , paragraph 1, nit:
> igure 1 describes an ESP Packet. Currently ESP is implemented in the kernel o
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Currently".

Section 1. , paragraph 2, nit:
> y to fit multiple purpose usage of these OS. However, completeness of the IPs
>                                    ^^^^^^^^
The plural demonstrative "these" does not agree with the singular noun "OS".

Section 1. , paragraph 2, nit:
>  as well as multipurpose scope of these OS is often performed at the expense
>                                  ^^^^^^^^
The plural demonstrative "these" does not agree with the singular noun "OS".

Section 1. , paragraph 3, nit:
> or constrained devices remains inter-operable with the standard ESP implemen
>                                ^^^^^^^^^^^^^^
This word is normally spelled as one.

Section 2. , paragraph 2, nit:
> ommunications, this document recommends to index SA with the SPI only. The i
>                              ^^^^^^^^^^^^^^^^^^^
The verb "recommends" is used with the gerund form.

Section 2.1. , paragraph 3, nit:
> g the key is being used. For example, a SPI might be encoded with the Securit
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.1. , paragraph 4, nit:
> h privacy and security concerns. Typically some specific values or subset of
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Typically".

Section 2.1. , paragraph 5, nit:
> ed information by ESP itself, these information may also be leaked otherwise
>                              ^^^^^^^^^^^^^^^^^
The plural demonstrative "these" does not agree with the singular noun
"information".

Section 2.1. , paragraph 5, nit:
> affic pattern before determining non random SPI can be used. Typically, temp
>                                  ^^^^^^^^^^
This expression is normally spelled as one or with a hyphen.

Section 2.1. , paragraph 5, nit:
> s, used outdoors may not leak privacy sensitive information and most of its t
>                              ^^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 2.1. , paragraph 5, nit:
> opened) may leak truly little privacy sensitive information outside the local
>                              ^^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 2.1. , paragraph 6, nit:
>  packet. The SN is set by the sender so the receiver can implement anti-repl
>                                    ^^^
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

Section 3. , paragraph 6, nit:
> ability to spoof and replay an acknowledgement is of limited interest and mig
>                                ^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

Section 3. , paragraph 6, nit:
> y discarding any packets that present a SN whose value is too much in the pa
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3. , paragraph 6, nit:
> s based on the largest possible value a SN can take over a session. When SN
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3. , paragraph 7, nit:
> ned devices, this document recommends to implement some rekey mechanisms (see
>                            ^^^^^^^^^^^^^^^^^^^^^^^
The verb "recommends" is used with the gerund form.

Section 4. , paragraph 5, nit:
> ns - may also reveal important privacy oriented information. Some constrained
>                                ^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 4. , paragraph 5, nit:
>  a sufficient tradeoff between the require energy to send additional payload
>                                    ^^^^^^^
The word "require" is not a noun. Did you mean "requirement"?

Section 5. , paragraph 4, nit:
> on the cryptographic suite used. Currently [RFC8221] only recommends cryptog
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Currently".

Section 5. , paragraph 4, nit:
> ent with a size different from zero. It length is defined by the security rec
>                                      ^^
It seems that the possessive pronoun "its" fits better in this context. Please
verify.

Section 7. , paragraph 2, nit:
> oss reboots, this document recommends to consider algorithms that are nonce
>                            ^^^^^^^^^^^^^^^^^^^^^^
The verb "recommends" is used with the gerund form.

Section 7. , paragraph 5, nit:
> of the encryption algorithm transform or the energy associated with it are es
>                                      ^^^
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

Section 7. , paragraph 10, nit:
> eration must follow [RFC4086]. In addition [SP-800-90A-Rev-1] provides approp
>                                  ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

Section 9. , paragraph 2, nit:
> In particular Scott Fluhrer suggested to include the rekey index in the SPI.
>                            ^^^^^^^^^^^^^^^^^^^^
The verb "suggested" is used with the gerund form.

[Ballot comment]
Thanks to Bob Briscoe for the TSVART review.

Sec 2.1. I find it odd that a node implementing IPSec is overburdened by generating a random number, but this is not my domain.

Sec 3. Bob and the authors had an interesting discussion on time-based SN and replay windows. It seems to me that the best way to do this would be for the receiver to keep a replay window of some number of packets rather than SNs. The receiver would then store the last, say, 10 packet SNs regardless of how many SNs that covered. This would avoid all the issues with the sender skipping many SNs.

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Mohit Sethi for the shepherd's write-up including the difficulties to reach WG consensus, I only regret the absence of justification for the intended status.

I hope that this helps to improve the document,

Regards,

-éric

## Section 2

"SA lookup needs to be performed using the longest match", I will let the SEC ADs to raise this point if required, but my understanding of IPsec is that it is not a "longest match" but a "full match on IP SA & SPI".

"the combination of a fixed value and the memory address of the SAD structure", should the 'fixed value' be changed on every reboot/reset of the IPsec code ?

Please expand "SAD" on first use.

## Section 2.1

The first paragraphs indicate that local SPI is for inbound traffic, but the last paragraph appears to be about outbound traffic from sensors. Unsure how to reconciliate the two parts of this section.

Probably just editorial in this informational document, but I wonder how to reconciliate the two proposed alternatives for SPI generation:

- section 2 use a 'low grade' random SPI

- section 2.1 use a combo of SAD + rekey index

## Section 3

When using time for sequence number (I like the idea BTW), what measures should be taken to handle the 32-bit rollover ?

Unsure whether I agree with the text around disabling anti-reply even for a IoT device, especially for actuators. The text has
  "These resources need also to balance that absence of anti-replay mechanism,
  may lead to unnecessary integrity check operations that might be
  significantly more expensive as well."

which appears too lenient IMHO.

# NITS 

s/32 bits field/32-bit field/

## Section 2

s/ valueand checks/ value and checks/

Mohit Sethi is the document Shepherd. Erik Kline is the responsible Area Director.

The document defines techniques for a minimal implementation of the Encapsulation Security Payload (ESP) defined in RFC 4303. It does not update or modify RFC 4303 in any way. In case of any conflicts RFC 4303 is treated as authoritative description.

The following people reviewed and provided comments: Tero Kivinen, Valery Smyslov, and Scott Fluhrer. Paul Wouters had expressed some reservations (https://mailarchive.ietf.org/arch/msg/lwip/xDcICiuALZ2ExF3qwRCnhCQC3A0/) during the call for adoption. He had reservations against relaxing the randomness requirements for SPI. Paul also noted that the argument for not having a sequence number counters are weak as AES-GCM and CHACHA20POLY1305 require a counter anyways. Paul was amenable to adopting the document as long as it was defining an ESP profile for resource-constrained devices and not modifying the protocol itself.

Edit: 7th June 2021: There was input from Paul Wouters after the WGLC: https://mailarchive.ietf.org/arch/msg/ipsec/y5lmwi_UmWqOJjUEKOnxHoTMLmA/. After an explanation from Tero, Paul wrote: "This email has helped a lot and I would really like to see some of this text included in the draft.". I believe the authors have updated the draft based on the email discussion: https://mailarchive.ietf.org/arch/msg/lwip/3rNPyEndI97eFNKjdItBCRFgir8/.

No issues were raised during the working group last call. The document shepherd has solicited reviews from security and IoT directorate as well as the gen-art team.

The Shepherd has verified that all of the authors have already disclosed any IPR related to this document, as is required by BCPs 78 and 79.

There are no DOWNREFs.

There are no IANA considerations.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-lwig-minimal-esp-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-08-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lwig-minimal-esp@ietf.org, ek.ietf@gmail.com, lwig-chairs@ietf.org, lwip@ietf.org, mohit.m.sethi@ericsson.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Minimal ESP) to Informational RFC


The IESG has received a request from the Light-Weight Implementation Guidance
WG (lwig) to consider the following document: - 'Minimal ESP'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-08-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a minimal implementation of the IP
  Encapsulation Security Payload (ESP) defined in RFC 4303.  Its
  purpose is to enable implementation of ESP with a minimal set of
  options to remain compatible with ESP as described in RFC 4303.  A
  minimal version of ESP is not intended to become a replacement of the
  RFC 4303 ESP.  Instead, a minimal implementation is expected to be
  optimized for constrained environment while remaining interoperable
  with implementations of RFC 4303 ESP.  Some constraints include
  limiting the number of flash writes, handling frequent wakeup / sleep
  states, limiting wakeup time, or reducing the use of random
  generation.

  This document does not update or modify RFC 4303, but provides a
  compact description of how to implement the minimal version of the
  protocol.  RFC 4303 remains the authoritative description.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/



No IPR declarations have been submitted directly on this I-D.

Thanks for the changes from -05 to -06.

A few more nits, but I'm going to request IETF LC for -06.  All of this
can wait for other feedback from IETF LC and SEC-DIR review.

[S1] [comment]

* Thanks for cleaning up the requirements language issue.  I think this mean
  that RFCs 2119 and 8174 can be removed from the references section.

[S2] [nit]

* s/valueand/value and/

[abstract] [nit]

* "Some constrains include" -> "Some constraints include"

[S1] [comment]

* Someone will inevitably point out that requirements terminology
  don't belong in an Informational document.

  Suggest removing this and lowercase all the terms throughout the
  document.  I know it doesn't seem ideal, but I don't think it
  really lowers the value of any of the recommendations in the doc.

[S2] [nit]

* "and limited traffic flow confidentiality" seems to be redundant
  with "provide confidentiality" earlier in the sentence.

  (It also raises the question of "in what way is it limited?",
  which just seems like an unnecessary digression.)

[S3] [nit]

* "used internal" -> "used internally"

* ", checks does not fall" -> "and checks it does not fall"

[S3.1] [question]

* "proceed to clean key update"

  What does this mean?  "clean"?

* "use of randomly generated SPI" ->
  "use of randomly generated SPIs"

* "leakage or privacy or security related information" ->
  "leakage of privacy or security related information"

[S4] [question]

* When too many packets are dropped (due to "out of window" conditions),
  does this cause the session to be renegotiated?

  If so, is it important to weight the computational impact of
  reestablishing IPsec crypto state relative to trying to maintain
  better record of the previously seen SNs?

[S4] [nit]

* "drop an non required anti replay protection" ->
  "drop a non-required anti-replay protection"

* "the support ESN is not" -> "the support of ESN is not"

[S5] [nit]

* "that were rely on" -> "that were relying on"

* "rather when" -> "rather than when"

[S6] [nit]

* "generate and receive dummy packet" ->
  "generate and receive dummy packets"

* "fix value" -> "fixed value"

[S8] [nit]

* "provided as indicative" -> "provided as information"?

* "Constraint devices" -> "Constrained devices"

* "energy associated to it" -> "energy associated with it"

[S10] [nit]

* "associated to the management" -> "associated with the management"

* "This usually include mechanisms to prevent a nonce to repeat
  for example."

  "This usually includes mechanisms to prevent a nonce from repeating,
  for example."

* "in conjunction of" -> "in conjunction with"

* "responsible to negotiate" -> "responsible for negotiating"

Mohit Sethi is the document Shepherd. Erik Kline is the responsible Area Director.

The document defines techniques for a minimal implementation of the Encapsulation Security Payload (ESP) defined in RFC 4303. It does not update or modify RFC 4303 in any way. In case of any conflicts RFC 4303 is treated as authoritative description.

The following people reviewed and provided comments: Tero Kivinen, Valery Smyslov, and others. Paul Wouters had expressed strong reservations (https://mailarchive.ietf.org/arch/msg/lwip/xDcICiuALZ2ExF3qwRCnhCQC3A0/) during the call for adoption. He had reservations against relaxing the randomness requirements for SPI. He also noted that the argument for not having a sequence number counters are weak as AES-GCM and CHACHA20POLY1305 require a counter anyways. Paul was amenable to adopting the document as long as it was defining an ESP profile for resource-constrained devices and not modifying the protocol itself.

Edit: 7th June 2021: There was some input from Paul Wouters after the WGLC that the ADs should be aware of: https://mailarchive.ietf.org/arch/msg/ipsec/y5lmwi_UmWqOJjUEKOnxHoTMLmA/

No issues were raised during the working group last call. The document shepherd has solicited reviews from security and IoT directorate as well as the gen-art team.

The Shepherd has verified that all of the authors have already disclosed any IPR related to this document, as is required by BCPs 78 and 79.

There are no DOWNREFs.

There are no IANA considerations.

Mohit Sethi is the document Shepherd. Erik Kline is the responsible Area Director.

The document defines techniques for a minimal implementation of the Encapsulation Security Payload (ESP) defined in RFC 4303. It does not update or modify RFC 4303 in any way. In case of any conflicts RFC 4303 is treated as authoritative description.

The following people reviewed and provided comments: Tero Kivinen, Valery Smyslov, and others. Paul Wouters had expressed strong reservations (https://mailarchive.ietf.org/arch/msg/lwip/xDcICiuALZ2ExF3qwRCnhCQC3A0/) during the call for adoption. He had reservations against relaxing the randomness requirements for SPI. He also noted that the argument for not having a sequence number counters are weak as AES-GCM and CHACHA20POLY1305 require a counter anyways. Paul was amenable to adopting the document as long as it was defining an ESP profile for resource-constrained devices and not modifying the protocol itself.

No issues were raised during the working group last call. The document shepherd has solicited reviews from security and IoT directorate as well as the gen-art team.

The Shepherd has verified that all of the authors have already disclosed any IPR related to this document, as is required by BCPs 78 and 79.

There are no DOWNREFs.

There are no IANA considerations.

Mohit Sethi is the document Shepherd. Erik Kline is the responsible Area Director.

The document defines techniques for a minimal implementation of the Encapsulation Security Payload (ESP) defined in RFC 4303. It does not update or modify RFC 4303 in any way. In case of any conflicts RFC 4303 is treated as authoritative description.

The following people reviewed and provided comments: Tero Kivinen, Valery Smyslov, and others. Paul Wouters had expressed strong reservations (https://mailarchive.ietf.org/arch/msg/lwip/xDcICiuALZ2ExF3qwRCnhCQC3A0/) during the call for adoption. He had reservations against relaxing the randomness requirements for SPI. He also noted that the argument for not having a sequence number counters are weak as AES-GCM and CHACHA20POLY1305 require a counter anyways. Paul was amenable to adopting the document as long as it was defining an ESP profile for resource-constrained devices and not modifying the protocol itself.

No issues were raised during the working group last call. The document shepherd has solicited reviews from security and IoT directorate as well as the gen-art team.

The Shepherd has verified that all of the authors have already disclosed any IPR related to this document, as is required by BCPs 78 and 79.

There are no DOWNREFs.

There are no IANA considerations.