From nobody Wed Oct 28 19:49:56 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D993A0AB5; Wed, 28 Oct 2020 19:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh3vt3Gc7RLz; Wed, 28 Oct 2020 19:49:39 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927E43A0A4F; Wed, 28 Oct 2020 19:49:37 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id d19so709706vso.10; Wed, 28 Oct 2020 19:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dmF6LfAELIjPMa5cN+B2yRQC0FO55sCmalSsgzVfZG4=; b=OFjq0fm0Pxt691AkpXNRPV4LNbT/pfOqNopmYZrIFlTEK2zjLudgmuXi+NfLL/Z/iF sZpc7/BqtnyYjzen75+Q/aXeVr38doPyPrX3uRp8klfNv7FQ3GUfTgpG6YF6ZfOweNPJ OJHRmJCBM1F3iTe9UehSPjq8K0vuNDvoOhSoqeLG1QPUxsdqljswAuReAiS2QZ5uP9ug cTGb03mJjmdx3fceQlkvctsOBlZ2N71klFrZmrZQeuVK3oH0FbbXKwj2McfiOho78xsX 6I+adKcbqSkSEVXVG+iWVcMBC3TEz8E2IqqAYQr0QDb/Kd7vVkhdzID/8IAy4IA57wwA zVlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dmF6LfAELIjPMa5cN+B2yRQC0FO55sCmalSsgzVfZG4=; b=TqnTQSyxqZ956w0JksERIKan9TgLJ1z8AjBcJpO9UgJLzd9Jef7YOE6wGwizxfpzye laNPTXxkk2xoQJp9KwyX+fpWdlvw2vmlxmmdCENHjXd1kTec2mM6115QawLjFFM5QGun eaBybWj+i5qYlSrhUzIkSSeoYA/ysEevKy023FNjqwKC6oH6gFOsOmQNlfJTUndLadxm 1cylN/1oMp4XmZDPL+yJMgk3QybvSt8ZAXTFELypPZl1y622Pk3UWJVK3rDCcOWpP00e rba+V07Hqw/OozOy/mQpituMZ1V9kCbQ9OmQ7EAuvJN81CKU3/dNvJ6bMA6PspVkbkle N8Lw== X-Gm-Message-State: AOAM533c1m5+5U7qJ3H6GoKCcZXaYAgWlUWiRgcJyJPYtwfhPrSMhjD6 E97dJgaYi4VB0XJb2LrvhXQjCR38Eht1+ZJwywuFDQms1aFhew== X-Google-Smtp-Source: ABdhPJyrcrZt3corghA8WlkQceWlT3iEev2z5Smjdnmvxi7M48LGhE8ALaRt3KqdV3oTBYeBu6J+pshPugBr7MVTDA0= X-Received: by 2002:a67:b405:: with SMTP id x5mr1606926vsl.4.1603939776496; Wed, 28 Oct 2020 19:49:36 -0700 (PDT) MIME-Version: 1.0 References: <060501d5a9da$b8552490$28ff6db0$@gmail.com> In-Reply-To: <060501d5a9da$b8552490$28ff6db0$@gmail.com> From: Daniel Migault Date: Wed, 28 Oct 2020 22:49:25 -0400 Message-ID: To: Valery Smyslov Cc: Tobias Guggemos , lwip@ietf.org, IPsecME WG Content-Type: multipart/alternative; boundary="0000000000009e886a05b2c65413" Archived-At: Subject: Re: [IPsec] Review of draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 02:49:49 -0000 --0000000000009e886a05b2c65413 Content-Type: text/plain; charset="UTF-8" Hi Valery, Thank you very much for the review. Your review was very helpful to improve the draft and we believe the new version has taken the reviews into account. Please find a more detailed description of the updates led by your reviews. Yours, Daniel On Tue, Dec 3, 2019 at 8:08 AM Valery Smyslov wrote: > Hi, > > I reviewed draft-ietf-lwig-minimal-esp-00. In general I think that the > document > provides useful guidelines on how ESP can be implemented on constrained > devices. > > General comment: the draft uses RFC2119 requirement language in several > places, > and it is not always clear whether it is just a repetition of the RFC4301 > requirements > or a new requirement imposed by this document. In general, I think it's > better not to include > the existing RFC4301/4303 requirements in the draft or make it absolutely > clear that these are not > new requirements if you need to mention them (adding a reference to a > corresponding section > in the RFCs). > We initially took this text as an editorial choice to quote or refer to useful original text. I understand it brings some confusion - unless we read it very carefully. I am tempted to agree that it might be clearer now that we removed the quoted text. In fact it is just commented so it would be easy to move back, if that would raise any concerns. > > Another general comment: sections 3-7 discuss how the corresponding ESP > packet fields > can be tweaked to deal with low resource devices. I think that for the > sake of clarity > the suggested measures must be summarized in each of these sections. > Currently > these sections contain quite a lot of discussion and no clear conclusions > what > is OK to do and in what situations. I think document will be more clear if > such > conclusions are put at the end of each section (currently some advises are > spread > over them). > > We tried to clarify the text. One difficulty is that recommendations can easily change over the use cases. For section 3, we mentioned that tweak applies to constraint devices for which handling 32 bit random SPI would cause an issue. I think that is now clearer. We also re-order some of the paragraphs so the discussion of a specific use cases remains localized. For section 4 we mentioned the SN that has an always increasing source may take advantage of it. We clarified that other recommendations concern all devices. For section 5 - 6 - 7 seems relatively generic. If you believe we could improve this, feel free to let us know. > > Specific comments: > > Section 3. > > When fix SPI are used, > it is RECOMMENDED the constraint node has as many SPI values as ESP > session per host IP address, and that SA lookup includes the IP > addresses. > > This is probably wrong if we take into considerations that SA may be > rekeyed. > Some words should be added either prohibiting rekeying ESP SAs in this case > or discussing that in case of rekey one will consume additional SPI values > for in fact the same SA. > > I agree. We now clearly mention that the number of SPI a peer needs to handle depends on the number of session and the rekying of these SA. We also moved the discussion of fixed SPIs to something more generic in order to provide more generic guidances. We reinforced also the need to rekey - and managed the keys in the security consideration section. SPI section has been updated as follows: """ 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, non random 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 non random SPI. When a constrained node limits the number of possible SPIs this limit should both consider the number of inbound SAs - possibly per IP addresses - as well as the ability for the node to rekey. SPI can typically be used to proceed to clean key update and the SPI value may be used to indicate which key is being used. This can typically be implemented by a SPI being encoded with the SAD entry on a subset of bytes (for example 3 bytes), while the remaining byte is left to indicate the rekey index. """ The security consideration has been updated as follows: """ The security of a communication provided by ESP is closely related to the security associated to the management of that key. This usually include mechanisms to prevent a nonce to repeat for example. When a node is provisioned with a session key that is used across reboot, the implementer MUST ensure that the mechanisms put in place remain valid across reboot as well. It is RECOMMENDED to use ESP in conjunction of key management protocols such as for example IKEv2 [RFC7296] or minimal IKEv2 [RFC7815]. Such mechanisms are responsible to negotiate fresh session keys as well as prevent a session key being use beyond its life time. When such mechanisms cannot be implemented and the session key is, for example, provisioned, the nodes SHOULD ensure that keys are not used beyond their life time and that the appropriated use of the key remains across reboots. When a node generates its key or when random value such as nonces are generated, the random generation MUST follow [RFC4086]. """ > When used indoor, the privacy information is stored in the encrypted > data and as such does not leak privacy. > > I cannot parse this :-) > > Not entirely sure what was the initial intent, but the current text mentions that privacy implication should also consider the exposure of the communication. Typically, an indoor sensor with local IP address may leak little privacy sensitive information with its SPI. Though this is not entirely no information. The current text is now: """ These devices, due to there limitations, are expected to provide limited information and how the use of non random SPI impacts privacy requires further analysis. Typically temperature sensors, wind sensors, used outdoor do not leak privacy sensitive information. When used indoor, privacy leakage outside the local network may be limited. """ > Such packet will not be rejected due to an SPI mismatch, but instead > after the signature check which requires more resource and thus make > DoS more efficient, especially for devices powered by batteries. > > I think this a very good argument against fixed (predictable) SPIs. > In fact, after reading through this section it seems to me that the > conclusion must be - predictable (fixed) SPIs SHOULD NOT be used. > > The current text does not mention fixed SPI anymore, but considers SPIs that are non randomly generated. We also clarify the text to say. Generate randomly the SPI when you can. Only if you really cannot consider the alternative. The reason I would not like to have SHOULD NOT is that it is still better to have IPsec with non randomly generated SPIs than no security. That said, we do not want to encourage non randomly generated SPIs. Values 0-255 SHOULD NOT be used. > > I believe these values MUST NOT be used with IPsec ESP, no? > Why "SHOULD NOT"? The values from this range are reserved > for other protocols utilizing ESP (e.g. SPI (1) was used in SKIP). > > This has been changed as well. Originally we had SHOULD NOT as not to prevent future usage with the reserved values. We set it to MUST NOT. > Section 4. > > I see no discussion regarding using ESN. I think there is generally no > point > to use ESN for constrained devices, but it can be useful if clock is used > to generate (E)SN, as suggested in the draft. In this case 64-bit numbers > can make sure that no two packets will be sent with the same ESN > (provided the clock has high resolution). > > This is correct that the former version did not provide indications on the use of ESN. This has been added in the new version. It is hard to recommend one or the other but what we would like is to emphasize is that incrementing the life time of the session with ESN is generally a bad idea and that providing a rekey mechanism is probably a better option. here is the text we come to: """ SN can be encoded over 32 bits or 64 bits - known as Extended Sequence Number (ESN). As per [RFC4303], the support ESN is not Migault & Guggemos Expires May 1, 2021 [Page 6] ^L Internet-Draft Minimal ESP October 2020 mandatory. The determination of the use of ESN is based on the largest possible value a SN can take over a session. When SN is incremented for each packet, the number of packets sent over the life time of a session may be considered. However, when the SN is incremented differently - such as when time is used - the maximum value SN needs to be considered instead. Note that the limit of messages being sent is primary determined by the security associated to the key rather than the SN. The security of the key used to encrypt decreases with the each message being sent and a node MUST ensure the limit is not reached - even though the SN would permit it. In a constrained environment, it is likely that the implementation of a rekey mechanism is preferred over the use of ESN. """ > Section 5. > > The purpose of padding is to respect the 32 bit alignment of ESP. > > It is not an accurate statement, the padding is also used when encryption > transform requires the input to be a multiple of some number of bytes. > Many modern transforms (based on GCM, CCM, CTR modes) don't have such > a requirement, but some (e.g. based on CBC mode) do have. > > Correct. We fixed with the following text: """ The purpose of padding is to respect the 32 bit alignment of ESP or block size expected by an encryption transform - such as AES-CBC for example. """ > Section 6. > > For interoperability, it is RECOMMENDED a minimal ESP > implementation discards dummy packets. > > I'm puzzled by this sentence. What else can the receiver do with dummy > packets other than discard? RFC4303 leaves him only this option :-) > > Your are correct. My main concern when writing these lines was that the implementation handled properly the dummy packets. In a word, do not get upset by them. One case I am thinking of is when ESP is used in transport mode an IP communication believes a dummy packet should be discarded rather than sent to the next transport layer. In tunnel mode things seem different as the next header is likely an IP header in which case everything else should be discarded. > > Nits: > Throughout the text: > s/fix SPI/fixed SPI > Actually we removed the fixed SPI. > s/constraint node/constrained node > s/algorythm/algorithm > fixed > > Section 2: > > s/IPsec suite protocol/IPsec protocol suite > > fixed > Section 3: > > However, for some constraint nodes, generating a random SPI may > consume to much resource, in which case SPI can be generated using > predictable functions or even a fix value. > > s/to/too > > fixed > When a constraint node uses fix value for SPIs, it imposes some > limitations on the number of inbound SA. This limitation can be > alleviate by how the SA look up is performed. When fix SPI are used, > it is RECOMMENDED the constraint node has as many SPI values as ESP > session per host IP address, and that SA lookup includes the IP > addresses. > > s/alleviate/alleviated > s/RECOMMENDED the/RECOMMENDED that the > > More specifically, traffic pattern MAY leak sufficient information in > itself. In other words, privacy leakage is a complex and the use of > random SPI is unlikely to be sufficient. > > s/MAY/may > > In addition, > predictable SPI enable an attacker to forge packets with a valid SPI. > > s/enable/enables > > fixed > Section 5: > > As a result, TFC cannot not be enabled with minimal, and > communication protection that were relying on TFC will be more > sensitive to traffic shaping. > > s/cannot not/cannot > s/minimal/minimal ESP > s/were relying/rely > > Section 7: > > Currently recommended > [RFC8221] only recommend crypto-suites with an ICV which makes the > ICV a mandatory field. > > s/recommend/recommends > > fixed > Section 8: > > The recommended suites to use are expect to evolve over time > and implementer SHOULD follow the recommendations provided by > [RFC8221] and updates. > > s/expect/expected > s/implementer/implementers > > fixed > Note that it > is not because a encryption algorithm transform is widely > deployed that is secured. > > s/a/an > fixed > > Regards, > Valery Smyslov. > > > -- Daniel Migault Ericsson --0000000000009e886a05b2c65413 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Valery,=C2=A0

Thank=C2=A0= you very much for the review. Your review was very helpful to improve the d= raft and we believe the new version has taken the reviews into account. Ple= ase find a more detailed description of the=C2=A0updates led by your review= s.=C2=A0

Yours,
=C2=A0Daniel

On Tue, Dec = 3, 2019 at 8:08 AM Valery Smyslov <smyslov.ietf@gmail.com> wrote:
Hi,

I reviewed draft-ietf-lwig-minimal-esp-00. In general I think that the docu= ment
provides useful guidelines on how ESP can be implemented on constrained
devices.

General comment: the draft uses RFC2119 requirement language in several pla= ces,
and it is not always clear whether it is just a repetition of the RFC4301 r= equirements
or a new requirement imposed by this document. In general, I think it's= better not to include
the existing RFC4301/4303 requirements in the draft or make it absolutely c= lear that these are not
new requirements if you need to mention them (adding a reference to a corre= sponding section
in the RFCs).

<mglt>
We= initially took this text as an editorial choice to quote or refer=C2=A0to = useful original text. I understand it brings some confusion - unless we rea= d it very carefully. I am tempted to agree that it might be clearer now tha= t we removed the quoted text. In fact it is just commented so it would=C2= =A0be easy to move back, if that would=C2=A0raise=C2=A0any concerns.
<= div>
</mglt>=C2=A0

Another general comment: sections 3-7 discuss how the corresponding ESP pac= ket fields
can be tweaked to deal with low resource devices. I think that for the sake= of clarity
the suggested measures must be summarized in each of these sections. Curren= tly
these sections contain quite a lot of discussion and no clear conclusions w= hat
is OK to do and in what situations. I think document will be more clear if = such
conclusions are put at the end of each section (currently some advises are = spread
over them).

<mglt>
We tried to clarify the text. = One difficulty is that recommendations can easily change over the use cases= .=C2=A0=C2=A0
For section 3, we mentioned that tweak applies to c= onstraint devices for which handling 32 bit random SPI would cause an issue= . I think that is now clearer. We also re-order some of the paragraphs so t= he discussion of a specific use cases remains localized.=C2=A0
Fo= r section 4 we mentioned the SN that has an=C2=A0always=C2=A0increasing sou= rce may take advantage=C2=A0of it. We clarified that other recommendations= =C2=A0concern all devices.=C2=A0
For section 5 - 6 -=C2=A0 7 seem= s relatively generic.=C2=A0
If you believe we could=C2=A0improve = this, feel free to let us know.

</mglt>=C2= =A0

Specific comments:

Section 3.

=C2=A0 =C2=A0When fix SPI are used,
=C2=A0 =C2=A0it is RECOMMENDED the constraint node has as many SPI values a= s ESP
=C2=A0 =C2=A0session per host IP address, and that SA lookup includes the I= P
=C2=A0 =C2=A0addresses.

This is probably wrong if we take into considerations that SA may be rekeye= d.
Some words should be added either prohibiting rekeying ESP SAs in this case=
or discussing that in case of rekey one will consume additional SPI values<= br> for in fact the same SA.

<mglt>
I agree. We now clearly mentio= n that the number of SPI a peer needs to handle depends on the number of se= ssion and the rekying=C2=A0of these SA. We also moved the discussion of fix= ed SPIs to something more generic in order to provide more generic=C2=A0gui= dances. We reinforced=C2=A0also the need to rekey - and managed the keys in= the security consideration section.=C2=A0


SPI section has been updated as fol= lows:

"""
=C2=A0 However,= for some constrained nodes, generating and handling 32 bit
=C2=A0= =C2=A0random SPI may consume too much resource, in which case SPI can be=C2=A0 =C2=A0generated using predictable functions or end up in a using a= subset
=C2=A0 =C2=A0of the possible values for SPI.=C2=A0 In fact, the = SPI does not
=C2=A0 =C2=A0necessarily need to be randomly generated.=C2= =A0 A node provisioned with
=C2=A0 =C2=A0keys by a third party - e.g. th= at does not generate them - and that
=C2=A0 =C2=A0uses a transform that = does not needs random data may not have such
=C2=A0 =C2=A0random generat= ors.=C2=A0 However, non random SPI and restricting their
=C2=A0 =C2=A0po= ssible values MAY lead to privacy and security concerns.=C2=A0 As a
=C2= =A0 =C2=A0result, this alternative should be considered for devices that wo= uld
=C2=A0 =C2=A0be strongly impacted by the generation of a random SPI = and after
=C2=A0 =C2=A0understanding the privacy and security impact of = generating non
=C2=A0 =C2=A0random SPI.

=C2=A0 =C2=A0When a const= rained node limits the number of possible SPIs this limit
=C2=A0 =C2=A0s= hould both consider the number of inbound SAs - possibly per IP
=C2=A0 = =C2=A0addresses - as well as the ability for the node to rekey.=C2=A0 SPI c= an
=C2=A0 =C2=A0typically be used to procee= d to clean key update and the SPI value
=C2=A0 =C2=A0may be used to indi= cate which key is being used.=C2=A0 This can typically
=C2=A0 =C2=A0be i= mplemented by a SPI being encoded with the SAD entry on a subset
=C2=A0 = =C2=A0of bytes (for example 3 bytes), while the remaining byte is left to=C2=A0 =C2=A0indicate the rekey index.
"""
T= he security consideration has been updated as follows:

=
"""
=C2=A0 The security of a communication pr= ovided by ESP is closely related to
=C2=A0 =C2=A0the security associated= to the management of that key.=C2=A0 This usually
=C2=A0 =C2=A0include = mechanisms to prevent a nonce to repeat for example.=C2=A0 When a
=C2=A0= =C2=A0node is provisioned with a session key that is used across reboot,=C2=A0 =C2=A0the implementer MUST ensure that the mechanisms put in place= remain
=C2=A0 =C2=A0valid across reboot as well.

=C2=A0 =C2=A0It= is RECOMMENDED to use ESP in conjunction of key management
=C2=A0 =C2= =A0protocols such as for example IKEv2 [RFC7296] or minimal IKEv2
=C2=A0= =C2=A0[RFC7815].=C2=A0 Such mechanisms are responsible to negotiate fresh<= br>=C2=A0 =C2=A0session keys as well as prevent a session key being use bey= ond its
=C2=A0 =C2=A0life time.=C2=A0 When such mechanisms cannot be imp= lemented and the
=C2=A0 =C2=A0session key is, for example, provisioned, = the nodes SHOULD ensure
=C2=A0 =C2=A0that keys are not used beyond their= life time and that the
=C2=A0 =C2=A0appropriated use of the key remains= across reboots.

=C2=A0 =C2=A0When a node generates its key or when = random value such as nonces are
=C2=A0 =C2=A0generated, the random gener= ation MUST follow [RFC4086].
"""
</mglt>=C2=A0
=C2=A0 =C2=A0When used indoor, the privacy information is stored in the enc= rypted
=C2=A0 =C2=A0data and as such does not leak privacy.

I cannot parse this :-)

<mglt>
Not entirely sure what was the= initial intent, but the current text mentions that privacy implication sho= uld also consider=C2=A0the exposure of the communication. Typically, an ind= oor sensor with local IP address may leak little privacy sensitive=C2=A0inf= ormation with its SPI. Though this is not entirely no information. The curr= ent text is now:

"""
Thes= e devices, due to there limitations, are expected to provide
=C2=A0 =C2= =A0limited information and how the use of non random SPI impacts privacy=C2=A0 =C2=A0requires further analysis.=C2=A0 Typically temperature sensor= s, wind
=C2=A0 =C2=A0sensors, used outdoor do not leak privacy sensitive= information.
=C2=A0 =C2=A0When used indoor, privacy leakage outside the= local network may be
=C2=A0 =C2=A0limited.
""&q= uot;

</mglt>=C2=A0
=C2=A0 =C2=A0 Such packet will not be rejected due to an = SPI mismatch, but instead
=C2=A0 =C2=A0after the signature check which requires more resource and thu= s make
=C2=A0 =C2=A0DoS more efficient, especially for devices powered by batterie= s.

I think this a very good argument against fixed (predictable) SPIs.
In fact, after reading through this section it seems to me that the
conclusion must be - predictable (fixed) SPIs SHOULD NOT be used.

<mglt>
The current text does not ment= ion fixed SPI anymore, but considers SPIs that are non randomly generated.= =C2=A0
We also clarify the text to say. Generate randomly the SPI= when you can. Only if you really cannot consider the alternative. The reas= on I would not like to have SHOULD NOT is that it is still better to have I= Psec with non randomly generated SPIs than no security. That said, we do no= t want to encourage non randomly generated SPIs.
</mglt>=C2= =A0

=C2=A0 =C2=A0Values 0-255 SHOULD NOT be used.

I believe these values MUST NOT be used with IPsec ESP, no?
Why "SHOULD NOT"? The values from this range are reserved
for other protocols utilizing ESP (e.g. SPI (1) was used in SKIP).

<mglt>
This has been changed as well.= Originally we had SHOULD NOT as not to prevent future usage with the reser= ved values. We set it to MUST NOT.
</mglt>=C2=A0
Section 4.

I see no discussion regarding using ESN. I think there is generally no poin= t
to use ESN for constrained devices, but it can be useful if clock is used to generate (E)SN, as suggested in the draft. In this case 64-bit numbers can make sure that no two packets will be sent with the same ESN
(provided the clock has high resolution).

<mglt>
This is correct that the forme= r version did not provide indications on the=C2=A0use of ESN. This has been= added in the new version. It is hard to recommend one or the other but wha= t we would like=C2=A0is to emphasize is that incrementing the life time of = the session with=C2=A0ESN is generally a bad idea and that providing a reke= y mechanism is probably a better option. here is the text we come to:
=

"""
=C2=A0SN can be encoded ov= er 32 bits or 64 bits - known as Extended
=C2=A0 =C2=A0Sequence Number (= ESN).=C2=A0 As per [RFC4303], the support ESN is not



Migault= & Guggemos =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires May 1, 2021 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6]
^L
Inter= net-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Minimal E= SP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0October 20= 20


=C2=A0 =C2=A0mandatory.=C2=A0 The determination of the use of= ESN is based on the
=C2=A0 =C2=A0largest possible value a SN can take o= ver a session.=C2=A0 When SN is
=C2=A0 =C2=A0incremented for each packet= , the number of packets sent over the life
=C2=A0 =C2=A0time of a sessio= n may be considered.=C2=A0 However, when the SN is
=C2=A0 =C2=A0incremen= ted differently - such as when time is used - the maximum
=C2=A0 =C2=A0v= alue SN needs to be considered instead.=C2=A0 Note that the limit of
=C2= =A0 =C2=A0messages being sent is primary determined by the security associa= ted
=C2=A0 =C2=A0to the key rather than the SN.=C2=A0 The security of th= e key used to
=C2=A0 =C2=A0encrypt decreases with the each message being= sent and a node MUST
=C2=A0 =C2=A0ensure the limit is not reached - eve= n though the SN would permit it.
=C2=A0 =C2=A0In a constrained environme= nt, it is likely that the implementation of a
=C2=A0 =C2=A0rekey mechani= sm is preferred over the use of ESN.
"""
=

=C2=A0
</mglt>
=C2=A0
Section 5.

=C2=A0 =C2=A0The purpose of padding is to respect the 32 bit alignment of E= SP.

It is not an accurate statement, the padding is also used when encryption transform requires the input to be a multiple of some number of bytes.
Many modern transforms (based on GCM, CCM, CTR modes) don't have such a requirement, but some (e.g. based on CBC mode) do have.

<mglt>
Correct. We fixed with the fol= lowing text:

"""
=C2=A0Th= e purpose of padding is to respect the 32 bit alignment of ESP or block siz= e expected by an encryption transform - such as AES-CBC for example.
"""
</mglt>=C2=A0
Section 6.

=C2=A0 =C2=A0For interoperability, it is RECOMMENDED a minimal ESP
=C2=A0 =C2=A0implementation discards dummy packets.=C2=A0

I'm puzzled by this sentence. What else can the receiver do with dummy<= br> packets other than discard? RFC4303 leaves him only this option :-)

<mglt>
Your are correct. My main conc= ern when writing these lines=C2=A0was that the implementation handled prope= rly the dummy packets. In a word, do not get upset by them. One case I am t= hinking of is when ESP is used in transport mode an IP communication believ= es a dummy packet should be discarded rather than sent to the next transpor= t layer. In tunnel mode things seem different as the next header is likely = an IP header in which case everything else should be discarded.=C2=A0
=
=C2=A0
</mglt>=C2=A0

Nits:
Throughout the text:
s/fix SPI/fixed SPI
<mglt>
Actually we= removed the fixed SPI.=C2=A0=C2=A0
</mglt>=C2=A0
s/constraint node/constrained node
s/algorythm/algorithm
<mglt>
fixed
</mglt>
=C2=A0

Section 2:

s/IPsec suite protocol/IPsec protocol suite

<mglt>
fixed
</mglt>= =C2=A0
Section 3:

=C2=A0 =C2=A0However, for some constraint nodes, generating a random SPI ma= y
=C2=A0 =C2=A0consume to much resource, in which case SPI can be generated u= sing
=C2=A0 =C2=A0predictable functions or even a fix value.=C2=A0

s/to/too

<mglt>
fixed
</mglt>= =C2=A0
=C2=A0 =C2=A0When a constraint node uses fix value for SPIs, it imposes som= e
=C2=A0 =C2=A0limitations on the number of inbound SA.=C2=A0 This limitation= can be
=C2=A0 =C2=A0alleviate by how the SA look up is performed.=C2=A0 When fix S= PI are used,
=C2=A0 =C2=A0it is RECOMMENDED the constraint node has as many SPI values a= s ESP
=C2=A0 =C2=A0session per host IP address, and that SA lookup includes the I= P
=C2=A0 =C2=A0addresses.

s/alleviate/alleviated
s/RECOMMENDED the/RECOMMENDED that the

=C2=A0 =C2=A0More specifically, traffic pattern MAY leak sufficient informa= tion in
=C2=A0 =C2=A0itself.=C2=A0 In other words, privacy leakage is a complex and= the use of
=C2=A0 =C2=A0random SPI is unlikely to be sufficient.

s/MAY/may

=C2=A0 =C2=A0In addition,
=C2=A0 =C2=A0predictable SPI enable an attacker to forge packets with a val= id SPI.

s/enable/enables

<mglt>
fixed
</mglt>= =C2=A0
Section 5:

=C2=A0 =C2=A0As a result, TFC cannot not be enabled with minimal, and
=C2=A0 =C2=A0communication protection that were relying on TFC will be more=
=C2=A0 =C2=A0sensitive to traffic shaping.=C2=A0

s/cannot not/cannot
s/minimal/minimal ESP
s/were relying/rely

Section 7:

=C2=A0 =C2=A0Currently recommended
=C2=A0 =C2=A0[RFC8221] only recommend crypto-suites with an ICV which makes= the
=C2=A0 =C2=A0ICV a mandatory field.

s/recommend/recommends

<mglt>
fixed
</mglt>= =C2=A0
Section 8:

=C2=A0 =C2=A0The recommended suites to use are expect to evolve over time =C2=A0 =C2=A0and implementer SHOULD follow the recommendations provided by<= br> =C2=A0 =C2=A0[RFC8221] and updates.

s/expect/expected
s/implementer/implementers

<mglt>
fixed
</mglt><= /div>
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0Note that it
=C2=A0 =C2=A0 =C2=A0 =C2=A0is not because a encryption algorithm transform = is widely
=C2=A0 =C2=A0 =C2=A0 =C2=A0deployed that is secured.=C2=A0

s/a/an
<mglt>
fixed
</mgl= t>=C2=A0

Regards,
Valery Smyslov.




--
Daniel Migault
Ericsson
--0000000000009e886a05b2c65413--