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

[[e-mail]]

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


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.

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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?


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


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


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


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


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