Re: [auth48] AUTH48: RFC-to-be 9333 <draft-ietf-lwig-minimal-esp-12> for your review

[Daniel Migault <[e-mail]>]

Hi, 

Thank you for teh careful review and please find below my comments/repsonse.

Yours, 
Daniel 

________________________________________
From: [e-mail] <[e-mail]>
Sent: Friday, November 4, 2022 2:47 PM
To: Daniel Migault; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: AUTH48: RFC-to-be 9333 <draft-ietf-lwig-minimal-esp-12> for your review

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.


1) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->


2) <!-- [rfced] Are the bits needed in the titles of Sections 3, 4, and 6?

Current:
   3.  Security Parameter Index (SPI) (32 Bits)
     3.1.  Considerations over SPI Generation
   4.  Sequence Number (SN) (32 Bits)
   5.  Padding
   6.  Next Header (8 Bits) and Dummy Packets
   7.  ICV

Perhaps:
   3.  Security Parameters Index (SPI)
     3.1.  Considerations over SPI Generation
   4.  Sequence Number (SN)
   5.  Padding
   6.  Next Header and Dummy Packets
   7.  ICV

<mglt>
The bit length does not need to be present in the title. However this is a convention we have taken to specify the size in the title for fixed size fields. We can remove the length of the title and make sure the size is mentioned early in the section. This is the case here with the first sentence being:  "[RFC4303] defines the SPI as a mandatory 32-bit field."

</mglt>
-->


3) <!-- [rfced] Please review "with [EHC-DIET-ESP] or [EHC-IKEv2]". Should this
text be updated in one of the following ways for clarity?

Current:
   With the adoption of IPsec by Internet of Things (IoT)
   devices with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC)
   with [EHC-DIET-ESP] or [EHC-IKEv2], these ESP implementations MUST
   remain interoperable with standard ESP implementations.

Perhaps:
   With the adoption of IPsec by Internet of Things (IoT)
   devices with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC)
   [EHC-DIET-ESP] [EHC-IKEv2], these ESP implementations MUST
   remain interoperable with standard ESP implementations.

<mglt>
The alternative above seems good to me.

NEW:
  With the adoption of IPsec by Internet of Things (IoT)
   devices with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC)
   [EHC-DIET-ESP] [EHC-IKEv2], these ESP implementations MUST
   remain interoperable with standard ESP implementations.

</mglt>

Or:
   With the adoption of IPsec by Internet of Things (IoT)
   devices with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC)
   with Diet-ESP [EHC-DIET-ESP] or Internet Key Exchange version 2 (IKEv2)
   [EHC-IKEv2], these ESP implementations MUST
   remain interoperable with standard ESP implementations.
-->


4) <!-- [rfced] How may we clarify "also require to use the" here?

Original:
   Nodes supporting multicast communications also require to use the IP
   addresses and thus SA lookup need to be performed using the longest
   match.

Perhaps:
   Nodes supporting multicast communications are also required to use IP
   addresses; thus, SA lookup needs to be performed using the longest
   match.

Or:
   Nodes supporting multicast communications also require the use of IP
   addresses; thus, SA lookup needs to be performed using the longest
   match.
<mglt>
This seems good to me:

NEW:
   Nodes supporting multicast communications also require the use of IP
   addresses; thus, SA lookup needs to be performed using the longest
   match.
</mglt>
-->


5) <!-- [rfced] We are having trouble understanding how the text after the dash
relates to the rest of the sentence. Please clarify.

Original:
   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.

Perhaps:
   In addition, some of these constrained
   devices are likely to have a limited number of SAs; for example, they are likely to
   only be indexed over 3 bytes.

<mglt>

The proposed text seems fine to us.

What we meant is that constrained devices - like a sensor - will use a very small number of SAs compared to a security gateway. As a result, thet sapce to index such SA can be significantly smaller. While the full range of indexes is 4 bytes, we can reasonably believe that sensor can deal with 3 bytes without any issue - or even less.
     

</mglt>
-->


6) <!-- [rfced] What does "It" refer to in the second sentence below? Should this
read "they" or perhaps the two sentences could be combined?

Original:
   Some specific values or
   subset of SPI values could reveal the models or manufacturer of the
   node implementing ESP.  It could also reveal some state such as "not
   yet rekeyed" or "rekeyed 10 times".

Perhaps:
   Some specific values or
   subsets of SPI values could reveal the model or manufacturer of the
   node implementing ESP or reveal a state such as "not
   yet rekeyed" or "rekeyed 10 times".

<mglt>
This is what we meant.
</mglt>
-->


7) <!-- [rfced] Please review "a very limited". Is a word missing here?

Original:
   If a constrained host uses a
   very limited or even just one application, the SPI itself could
   indicate what kind of traffic (eg the kind of application typically
   running) is transmitted.

<mglt>
We meant a very limited number of applications  - eventually a single one. I propose the following wording.

OLD:
   If a constrained host uses a
   very limited or even just one application, the SPI itself could
   indicate what kind of traffic (eg the kind of application typically
   running) is transmitted.

NEW:
   If a constrained host uses a
   very limited number of applications, eventually a single one, the SPI itself could
   indicate what kind of traffic (eg the kind of application typically
   running) is transmitted.

</mglt>
-->


8) <!-- [rfced] Is "correlated by" correct, or should this read "correlated
with"? Also, are both instances of "further" needed here?

Original:
   This could be further correlated by
   encrypted data size to further leak information to an observer on the
   network.

Perhaps:
   This could also be correlated with
   encrypted data size to further leak information to an observer on the
   network.

<mglt>
I suspect that correlated is used with 'with' and not 'by'. I am fine with the proposed wording.
</mglt>


-->


9) <!-- [rfced] FYI - We updated "its" to "their" as the antecedent seems to be
the plural "sensors". Also, we updated "may not" to "do not".

Original:
   Typically temperature sensors, wind sensors, used
   outdoors may not leak privacy sensitive information and most of its
   traffic is expected to be outbound traffic.

Updated:
   Typically, temperature and wind sensors that
   are used outdoors do not leak privacy-sensitive information, and
   most of their traffic is expected to be outbound traffic.

<mglt>
I am fine with the wording.
</mglt>
-->


10) <!-- [rfced] We had trouble parsing this sentence. Please let us know how we
may update for clarity.

Original:
   The RECOMMENDED way for multipurpose ESP implementation is to
   increment a counter for each packet sent.

Perhaps:
   It is RECOMMENDED that multipurpose ESP implementations increment a
   counter for each packet sent.

<mglt>
This works for me.
</mglt>
-->


11) <!-- [rfced] Please clarify "requires to store any information" here.

Original:
   This requires to store any information in a stable storage - such as
   flash memory - that can be restored across sleeps.

Perhaps:
   This requires devices to store any information in stable storage
   that can be restored across sleeps (e.g., flash memory).

Or:
   This requires any information to be stored in stable storage that
   can be restored across sleeps (e.g., flash memory).

<mglt>
 I think that both formulation work.
</mglt>
-->


12) <!-- [rfced] Is "property" the correct word choice here? Or would "ability" or
something else be better?

Original:
   The size of the window should depend on the
   property of the network to deliver packets out of order.

<mglt>
I am wondering is characteristic is not more appropriated.

NEW:

The size of the window should depend on the
 network characteristic to deliver packets out of order.

</mglt>
-->


13) <!-- [rfced] Will "is too much in the past" be clear to readers?

Original:
   Typically, when the
   sending peer is using SN based on time, anti-replay may be
   implemented by discarding any packets that present a SN whose value
   is too much in the past.

<mglt>
This seems to me clear.
</mglt>
-->


14) <!-- [rfced] Will readers know what "It" refers to here?

Original:
   It could accept any SN as long as it is higher than the
   previously received SN.

<mglt>
I think so, though this may be replaced by 

NEW:
It could accept any SN as long as that received SN is higher than the
   previously received SN.


</mglt>
-->


15) <!-- [rfced] Please confirm that the pointer to "Section 10" is correct
here. We ask because we do not see "rekey" in Section 10.

Original:
   Even for constrained devices, it is RECOMMENDED
   to implement some rekey mechanisms (see Section 10).

<mglt>
This is correct - we use key management in section 10 which includes rekey.
</mglt>
-->


16) <!-- [rfced] Should "Data Payload" read "Payload Data" here to match the field
name in Figure 1?

Original:
   This would typically be the case when the Data Payload is of fixed size.

<mglt>
Correct:

NEW:
 This would typically be the case when the Payload Data is of fixed size.

</mglt>
-->


17) <!-- [rfced] Please review "some application use". Should this read "some
applications"? Or is another meaning intended?

Original:
   In addition, some
   application use - such as health applications - could leak important
   privacy oriented information.

Perhaps:
   In addition, some
   applications (such as health applications) could leak important
   privacy oriented information.


<mglt>
The is correct.
</mglt>
-->


18) <!-- [rfced] Please review "authenticated encryption (AEAD)". Should the
complete expansion, i.e., "Authenticated Encryption with Associated Data
(AEAD)", be used?

Original:
   ESP can be used to authenticate only
   (ENCR_NULL) or to encrypt the communication.  In the latter case,
   authenticated encryption (AEAD) is
   RECOMMENDED [RFC8221].

Perhaps:
   ESP can be used to authenticate only
   (ENCR_NULL) or to encrypt the communication.  In the latter case,
   Authenticated Encryption with Associated Data (AEAD) is
   RECOMMENDED [RFC8221].

<mglt>
Seems better to me.
</mglt>
-->


19) <!-- [rfced] Will it be clear to readers how the text after the dash relates
to the rest of the sentence? Also, is a unit of measure needed with "2"
(maybe "bits")?

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

<mglt>

Adding the unit will be clearer. I propose the following text:

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

</mglt>
-->


20) <!-- [rfced] FYI, we have used the <sup> element for superscript in this
document. You can see how it looks in the last paragraph of Section 4.

Note: In the HTML and PDF, it appears as superscript.  In the text output,
<sup> generates a^b.  -->


21) <!-- [rfced] Terminology

a) "Next Header" is capitalized in the document except in two
instances of "no next header". Should this read either "no Next Header"
or "No Next Header" or "no Next Header"? Or is the current okay as is?

<mglt>
RFC4303 mentions "no next header" so we believe that the current wording is ok.
</mglt>

b) FYI - We updated "Security Parameter Index" to read "Security Parameters
Index" per RFC 4303.

<mglt>
Thank you. That is what should have been written.
</mglt>


c) We note inconsistencies in the terms below throughout the text.  Should
these be uniform? If so, please let us know which form is preferred.

minimal IKEv2 vs. Minimal IKEv2

minimal ESP vs. Minimal ESP

rekey mechanism vs. rekeying mechanism

<mglt>

It seems to me more consistent with RFC7815 to have:

minimal IKEv2 (from RFC7815)
minimal ESP (to mimic RFC7815)
rekeying mechanism may also be more consistent by I do not have a strong preference.

</mglt>
-->


22) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

For example, please consider whether the following should be updated:

dummy

<mglt>
This is really taking the wording of 4303. I think that is better to keep it as it is. However if that needs to be changed, we shoudl mentioned this new designation is refered as "dummy" in RFC4303.
</mglt>

-->


23) <!-- [rfced] Some author comments are present in the XML. Please confirm that
no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->

<mglt>
Most of the comments are addressed by this email. There are additional comments but it remains unclear to me if these a text changed by the rfc editor or comments we left in the xml. That said, I have not seen anything that shocked me.
</mglt>
Thank you.

RFC Editor/st/rv



On Nov 4, 2022, at 11:43 AM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2022/11/04

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.

Planning your review
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

  Please review and resolve any questions raised by the RFC Editor
  that have been included in the XML file as comments marked as
  follows:

  <!-- [rfced] ... -->

  These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors

  Please ensure that you review any changes submitted by your
  coauthors.  We assume that if you do not speak up that you
  agree to changes submitted by your coauthors.

*  Content

  Please review the full content of the document, as this cannot
  change once the RFC is published.  Please pay particular attention to:
  - IANA considerations updates (if applicable)
  - contact information
  - references

*  Copyright notices and legends

  Please review the copyright notice and legends as defined in
  RFC 5378 and the Trust Legal Provisions
  (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

  Please review the markup in the XML file to ensure that elements of
  content are correctly tagged.  For example, ensure that <sourcecode>
  and <artwork> are set correctly.  See details at
  <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

  Please review the PDF, HTML, and TXT files to ensure that the
  formatted output, as generated from the markup in the XML file, is
  reasonable.  Please note that the TXT will have formatting
  limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:

  *  your coauthors

  *  [e-mail] (the RPC team)

  *  other document participants, depending on the stream (e.g.,
     IETF Stream participants are your working group chairs, the
     responsible ADs, and the document shepherd).

  *  [e-mail], which is a new archival mailing list
     to preserve AUTH48 conversations; it is not an active discussion
     list:

    *  More info:
       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

    *  The archive itself:
       https://mailarchive.ietf.org/arch/browse/auth48archive/

    *  Note: If only absolutely necessary, you may temporarily opt out
       of the archiving of messages (e.g., to discuss a sensitive matter).
       If needed, please add a note at the top of the message that you
       have dropped the address. When the discussion is concluded,
       [e-mail] will be re-added to the CC list and
       its addition will be noted at the top of the message.

You may submit your changes in one of two ways:

An update to the provided XML file
— OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes.  Information about stream managers can be found in
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files
-----

The files are available here:
  https://www.rfc-editor.org/authors/rfc9333.xml
  https://www.rfc-editor.org/authors/rfc9333.html
  https://www.rfc-editor.org/authors/rfc9333.pdf
  https://www.rfc-editor.org/authors/rfc9333.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9333-diff.html
  https://www.rfc-editor.org/authors/rfc9333-rfcdiff.html (side by side)

Alt-diff of the text (allows you to more easily view changes
where text has been deleted or moved):
  https://www.rfc-editor.org/authors/rfc9333-alt-diff.html

Diff of the XML:
  https://www.rfc-editor.org/authors/rfc9333-xmldiff1.html

The following files are provided to facilitate creation of your own
diff files of the XML.

Initial XMLv3 created using XMLv2 as input:
  https://www.rfc-editor.org/authors/rfc9333.original.v2v3.xml

XMLv3 file that is a best effort to capture v3-related format updates
only:
  https://www.rfc-editor.org/authors/rfc9333.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9333

Please let us know if you have any questions.

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9333 (draft-ietf-lwig-minimal-esp-12)

Title            : Minimal IP Encapsulating Security Payload (ESP)
Author(s)        : D. Migault, T. Guggemos
WG Chair(s)      : Zhen Cao, Mohit Sethi

Area Director(s) : Erik Kline, Éric Vyncke