Re: [Iot-directorate] [Lwip] Iotdir last call review of draft-ietf-lwig-minimal-esp-03

[Daniel Migault <[e-mail]>]

Hi Nancy,

Thank you very much for your review. Please see inline my responses. I
believe all concerns raised have been addressed. I also believe the current
text addresses some concerns also raised by Paul W.

The current version can be found here:
https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/1/commits/fb9393a246298e37adcf2683afa2061a40b4ed89

I think there are however three remaining issues that might get further
discussions. For all of these I provided a response, but I am unsure it
really addresses the three concerns below:

----
ISSUE 1
----
- I might challenge due to potential collision attacks that at
most, 2^32-1 packets may be sent before the SPI *must* rekey, so the SN and
how
it is used is part of the security context for the SPI/SA.  I might also
challenge that a recommendation for using a rekey mechanism is warranted
because constrained devices tend to stay up for very, very, very long
periods
of time and even with an ESN there can be exhaustion :-)

I am missing the concern. I understand the first concern is that the
current text seems to push the limit of packets being sent being determined
by the SN as opposed to cryptographic properties. If my understanding is
correct, I have the current text seems clear that crypto properties are
given priorities. I suspect more guidance would be given. If that is the
case, I find it difficult as these guidances are really based on the
cryptographic algorithm and the key sizes. In any case, if I am
missing something, feel free to propose some text.

"""
Note that the limit of messages being sent is primarily determined by the
security associated with the key rather than the SN.
The security of all data protected under a given key decreases slightly
with each message and a node MUST ensure the limit is not reached - even
though the SN would permit it.
"""

I understand the second concern as that current text is read as rekey
mechanisms are recommended only when there is a risk the SN get exhausted.
Our intention was to read the text as even if ESN raises the limit to an
acceptable limit, it is preferred to have a rekey mechanism. I propose the
following text to clarify the meaning:

OLD:
In a constrained environment, it is likely that the implementation of a
rekey mechanism is preferred over the use of ESN.

NEW:
Estimation of the maximum number of packets to be sent by a node is always
challenging and as such should be considered cautiously as nodes could be
online for much more time than expected.
Even for constrained devices, it is RECOMMENDED to implement some rekey
mechanisms (see <xref target="sec-security-considerations"/>).
</mglt>
---
ISSUE 2
---
-
Resilience to nonce reuse goes to the SN considerations as well (see my
comments for Section 4).

---
ISSUE 3
---

> Currently RFC8452 is not cited as negotiated ciphers in RFC 8221, so
> considerations for 96bit nonce which doesn’t fit into the ESP header, so
> while
> a general alternative not sure how you would apply it to ESP unless
> changes are
> made?

<mglt>

This is correct that AES-GCM-SIV was not mentioned in RFC8221, and I
mentioned it as an example. Now, it seems more problematic to have an
example of a cipher suite that does not work for ESP.
I am balanced between indicating that its support is not defined with ESP
so the reader still has a reference to an example of such a cipher suite.

I will raise this issue to the WG, but currently the text is as follows:

"""
When the key is likely to be re-used across reboots, it is RECOMMENDED to
consider transforms that are nonce misuse
resistant such as AES-GCM-SIV for example<xref target="RFC8452"/>. Note
however that AES-GCM-SIV has not yet been defined for ESP.
"""
</mglt>

>
Yours,
Daniel



On Fri, Mar 26, 2021 at 7:27 PM Nancy Cam-Winget via Datatracker <
[e-mail]> wrote:

> Reviewer: Nancy Cam-Winget
> Review result: Ready with Issues
>
> General Comments
> The document flows relatively well; I expect that the editors will fix
> editorial/grammatical issues and I’ve noted a couple below. I did have some
> questions to some of the descriptions where I expected guidance but read
> the
> text as being more considerations so asked questions for clarification.
>
> Technical comments:
> Section 2:
>  - The first paragraph speaks to other drafts defining minimal
>  exchanges/operations and compression to serve IoT;
> and then states “This document describes the minimal properties and ESP
> implementation needs to meet.” Needs more clarification, is it so that it
> can
> interoperate with non-minimal ESP (e.g. RFC 4303 as defined) or to
> Interoperate
> given a set of constraints e.g. the minimal set to be defined in this
> document
> including RFC 7815, et al? I think it is the former but the flow of the
> paragraph makes it unclear….
>
> <mglt>

The purpose of the document is to provide guidance to build a minimal ESP
implementation that remains interoperable with the RFC4303 ESP. In addition
to the properties that needs to be met by a minimal ESP implementation, the
document also provides some guidance on how the properties may be
implemented while also meeting some constraints of specific environments.
Here is the text I propose:

OLD:
This document describes the minimal properties and ESP implementation needs
to meet.


NEW:
This document describes the minimal properties an ESP implementation needs
to meet to remain interoperable with RFC4303 ESP.
In addition, this document also provides a set of options to implement
these properties under certain constrained environments.
</mglt>

Section 3:
> - Why is it RECOMMENDED to have a randomly generated SPI?  The next
> paragraph
> claims that it is not necessary, which in reading RFC 4303 is the case.  So
> this statement seems to contradict The following paragraph that relaxes
> this
> constraint.  But the rationale doesn’t seem to coincide; e.g. “A node
> provisioned with keys by a third party ….uses a transform that doesn’t not
> needs random data…” Isn’t relevant to the SPI which is intended to be an
> Index….so better clarification of the security concerns are required.
> Perhaps
> on the relaxation, inclusion of consideration of non-reuse and uniqueness
> of
> the SPI to reduce replay and maybe cross SA attacks should also be
> included.
>
> <mglt>
Thanks for these comments, that is helpful to clarify this section. While
SPI do not need to be random this is usually how SPI are generated. As a
result, using non random values raised a lot of discussions while the use
of random did not raise any discussions. I think that is the reason the two
visions have been documented in an unbalanced way.
I agree that the text could be clearer and much more concise. I have
restructured the full section exposing what 4303 mentions regarding the
generation of the SPI, what and whay SPI are generally generated randomly
as well as why and how non random SPI may be generated.  I have also added
a section that groups consideration on SPI generation. I hope this is
clearer now.

NEW:
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
value, checks 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.

However, some constrained nodes may be less concerned by the privacy
properties associated to SPIs randomly generated.
Examples of such nodes might include sensors looking to reduce their code
complexity, in which case the use of a predictive function to generate the
SPI might be preferred over the generation and handling of random values.
An example of such predictable function may consider the combination of a
fixed value and the memory address of the SAD structure.
For every incoming packet, the node will be able to point the SAD structure
directly from the SPI value. This avoids having a separate and additional
binding between SPI and SAD entries that is involved for every incoming
packet.

OLD:
 <t> It is RECOMMENDED to index each inbound session with a SPI randomly
generate over 32 bits.
Upon the generation of a SPI the peer checks the SPI is not already used
and 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.
A random generation provides a stateless way to generate the SPIs, while
keeping the probability of collision between SPIs relatively low. </t>

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

- The last paragraph goes to the consideration that constrained devices may
> suffer from long lag times Between breach-patch availability to actual
> deployment (or lack thereof).  But that rationale, imho, Is not the
> motivation
> for predictable SPIs; unless the consideration is more that if they don’t
> adhere to Appropriate key refreshes and SPI rotation that could lead to
> replay
> attacks. On the privacy front, Predictability of SPIs in particular SAs
> could
> over time help an attacker gain more information about The actual devices
> and
> behavior.
>
> <mglt>
If a device of type "A" implements ESP that takes very limited values of
SPI, an observer that monitors the traffic that observes such values will
be able to define that there is a high probability the device is of type
"A". When these devices have vulnerabilities, the observer this information
may be used by the observer to infer potential vulnerabilities the device
is subject to. In my mind the observer is an attacker, so I would be
tempted to consider this as a drawback.
>From your text I have the impression that the use of these non random
values for SPI may be used by an administrator to monitor potential
vulnerabilities in its network - which could be seen as a feature. This is
how I am reading the first sentence of your comment, but I might be missing
it.

In any case, I agree that this is not the rationale for using non random
SPIs. In my view that is more a drawback. "In addition" was intended to
raise an additional security concern which is that knowing the SPI or not
changing the SPI will ease an attacker to forge packets with a valid SPI. I
agree with you that this is also associated with any long term ESP sessions
and can be removed.

As mentioned above, I have restructured and shortened the text and here is
the content of the "Considerations over SPI generation" section:

NEW:

SPI that are not randomly generated over 32 bits MAY lead to privacy and
security concerns.
As a result, the use of alternative designs requires careful security and
privacy reviews.
This section provides some considerations upon the adoption of alternative
designs.


Note that SPI value is used only for inbound traffic, as such the SPI
negotiated with IKEv2 RFC7296 or RFC7815 by a peer, is the value used by
the remote peer when it sends traffic.
As SPI is only used for inbound traffic by the peer, this allows each peer
to manage the set of SPIs used for its inbound traffic.
Similarly, the privacy concerns associated with the generation of nonrandom
SPI is also limited to the incoming traffic.

When alternate designs are considered, it is likely that the number of
possible SPIs will be limited.
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 Security
Association Database (SAD) entry on a subset of bytes (for example 3
bytes), while the remaining byte is left to indicate the rekey index.

The use of a smaller number of SPIs across communications comes with
privacy and security concerns.
Typically some specific values or subset of SPI values may reveal the
models or manufacturer of the node implementing ESP.
This may raise some privacy issues as an observer is likely to be able to
determine the constrained devices of the network.
In some cases, these nodes may host a very limited number of applications -
typically a single application - in which case the SPI would provide some
information related to the application of the user.
In addition, the device or application may be associated with some
vulnerabilities, in which case specific SPI values may be used by an
attacker to discover vulnerabilities.

While the use of randomly generated SPI may reduce the leakage or privacy
or security related information by ESP itself, these information may also
be leaked otherwise and a privacy analysis should consider at least the
type of information as well the traffic pattern.
Typically, temperature sensors, wind sensors, used outdoors do 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) leaks truly little privacy sensitive
information outside the local network.


</mglt>

> Section 4:
> - The third/fourth paragraph speaks to the potential use of a clock for the
> sequence counter, which if using an absolute clock with sufficiently fine
> granularity could maybe work.  But stronger language to that granularity is
> required, the example lists one where periodicity “may be” every 60sec, but
> there are many devices who will have millisecond (or finer?)
> granularity….so
> stronger caution and care descriptions are required.


 <mglt>
The third paragraph says that even if a node knows the other peers does not
implement antireplay, it must increase the SN.

The 4th paragraphe details one way to increment SN based on time. On a
sender side, the only constraint is that the SN never repeats, so the
granularity seems to me that the clock must be that every packet is sent at
a different time. If I interpret correctly the your comment, I think the
text below addresses the concern.

"""
 Using time for SN would guarantee a strictly
   increasing function and avoid storing any additional values or
   context related to the SN.  When the use of a clock is considered,
   one should take care that packets associated to a given SA are not
   sent with the same time value.
"""

Maybe the concern is regarding the synchronization between the sender and
the receiver. The current text mentions that if the sender uses a clock and
the receiver considers an incremental counter value, an anti replay
mechanism is likely to reject the packets.
I think that we could add text to mention that an anti replay window should
take into account time derivation of the devices. I think that both
recommendations should be moved to the receiver paragraph.
So the concern of the receiver implementing a counter base anti-replay
mechanism remains in this section but anti replay mechanisms related to SN
have been moved to the receiving paragraph.

I have also reworded some text in the sendin paragraph, but not changed the
main structure. Here is the current text:

Usually, SN is generated by incrementing a counter for each packet sent.
A constraint device may avoid maintaining this context and use another
source that is known to always increase.
Typically, constraint nodes using 802.15.4 Time Slotted Channel Hopping
(TSCH), whose communication is heavily dependent on time, can take
advantage of their clock to generate the SN.
A lot of IoT devices are in a sleep state most of the time wake up and are
only awake to perform a specific operation before going back to sleep.

They do have separate hardware that allows them to wake up after a certain
timeout, and most likely also timers that start running when the device was
booted up, so they might have a concept of time with certain granularity.
This requires to store any information in a stable storage - such as flash
memory - that can be restored across sleeps.
Storing information associated with the SA such as SN requires some read
and writing operation on a stable storage after each packet is sent as
opposed to SPI or keys that are only written at the creation of the SA.
Such operations are likely to wear out the flash, and slow down the system
greatly, as writing to flash is not as fast as reading.
Their internal clocks/timers might not be very accurate, but they should be
enough to know that each time they wake up their time is greater than what
it was last time they woke up.
Using time for SN would guarantee a strictly increasing function and avoid
storing any additional values or context related to the SN.
When the use of a clock is considered, one should take care that packets
associated to a given SA are not sent with the same time value.
Note however that standard receivers are generally configured with
incrementing counters and, if not appropriately configured, the use of a
significantly larger SN may result in the packet out of the receiver's
windows and that packet being discarded.

</mglt>

> - The considerations for a
> receiver seems lengthy and am not sure of the point being stressed, other
> than
> to RECOMMEND the use of anti-replay protection.  I expected a description
> for
> the need of a replay window and the window being set to discriminate to the
> worst case scenario (e.g. if on a wireless noisy medium where there is
> packet
> loss, then there may be a say 10ms loss/retry window).  I am not
> understanding
> the example of the temperature sensor and the relevance to the SN.

More
> concerning to me is the last sentence: “A node MAY drop anti-replay
> …..instead
> implant its own internal mechanism”? Is the intent to say if the receiver
> has a
> different algorithm independent of the use of SN, then it MAY choose that
> over
> the use of SN?

<mglt>
The intent of the paragraph is to indicate that anti replay is not
mandatory.
The paragraph has been slightly updated to clarify the sensor use case
where implementing anti replay comes with similar issues for a
constraint device as the use of a counter - that is storing a value in a
memory for any received packets.
There are cases where the anti replay mechanism might not be as necessary
as we may think. We expose some anti replay mechanisms that are based on
time and mention some considerations to set the window.
However, we do not provide explicit value as these are expected to be
dependent on the network or type of application.
I hope the text exposes in a clearer way the use case of the sensor as well
as the purpose of the paragraph. Here is the current text:

For inbound traffic, it is RECOMMENDED that any receiver provides
anti-replay protection, and the size of the window depends on the ability
of the network to deliver packets out of order.
As a result, in an environment where out of order packets is not possible
the window size can be set to one.
However, while RECOMMENDED, there are no requirements to implement an
anti-replay protection mechanism implemented by IPsec.
Similarly to the SN the implementation of anti replay protection may
require the device to write the received SN for every packet, which may in
some cases come with the same drawbacks as those exposed for SN.

As a result, some implementations MAY drop an non required anti replay
protection especially when the necessary resource involved overcomes the
benefit of the mechanism.
A typical example might consider an IoT device such as a temperature sensor
that is sending a temperature every 60 seconds, and that receives an
acknowledgement from the receiver.
In such cases, the ability to spoof and replay an acknowledgment is of
limited interest and may not justify the implementation of an anti replay
mechanism.

Receiving peers may also implement their own anti-replay mechanism.
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.
Note that such mechanisms may consider clock drifting in various ways in
addition to acceptable delay induced by the network to avoid the anti
replay windows rejecting legitimate packets.
When a packet is received at a regular time interval, some variant of time
based mechanisms may not even use the value of the SN, but instead only
consider the receiving time of the packet.

</mglt>

>

> - I might challenge due to potential collision attacks that at
> most, 2^32-1 packets may be sent before the SPI *must* rekey, so the SN
> and how
> it is used is part of the security context for the SPI/SA.  I might also
> challenge that a recommendation for using a rekey mechanism is warranted
> because constrained devices tend to stay up for very, very, very long
> periods
> of time and even with an ESN there can be exhaustion :-)
>
>  <mglt>
---
ISSUE 1
---
I am missing the concern. I understand the first concern is that the
current text seems to push the limit of packets being sent being determined
by the SN as opposed to cryptographic properties. If my understanding is
correct, I have the current text seems clear that crypto properties are
given priorities. I suspect more guidance would be given. If that is the
case, I find it difficult as these guidances are really based on the
cryptographic algorithm and the key sizes. In any case, if I am
missing something, feel free to propose some text.

"""
Note that the limit of messages being sent is primarily determined by the
security associated with the key rather than the SN.
The security of all data protected under a given key decreases slightly
with each message and a node MUST ensure the limit is not reached - even
though the SN would permit it.
"""

I understand the second concern as that current text is read as rekey
mechanisms are recommended only when there is a risk the SN get exhausted.
Our intention was to read the text as even if ESN raises the limit to an
acceptable limit, it is preferred to have a rekey mechanism. I propose the
following text to clarify the meaning:

OLD:
In a constrained environment, it is likely that the implementation of a
rekey mechanism is preferred over the use of ESN.

NEW:
Estimation of the maximum number of packets to be sent by a node is always
challenging and as such should be considered cautiously as nodes could be
online for much more time than expected.
Even for constrained devices, it is RECOMMENDED to implement some rekey
mechanisms (see <xref target="sec-security-considerations"/>).
</mglt>

> Section 5:
> - If a constrained device does use AES-CBC then padding may be needed,
> shouldn’t that be considered here? That is, it seems that padding is
> dependent
> on the cipher negotiated, right? - “TFC cannot be enable with minimal ESP”
> seems subjective, given that this is the guidelines perhaps it is a SHOULD
> NOT
> (or NOT RECOMMENDED)?
>
> <mglt>
I interpret your concern as if the current document were not mandating the
padding. My understanding of the section is that we mostly mention how the
padding should be built and that the format should not be checked by the
minimal implementation.
I also believe that the case of AES-CBC has been addressed with the
following sentence. Feel free however to let me know if I mis-interpreted
your comment.

"""
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.
ESP MUST have at least one padding byte Pad Length that indicates the
padding length.
"""

I think it makes sense to have it as a recommendation, and here is the new
text:

OLD:
As such TFC is not
   expected to be supported by a minimal ESP implementation.

NEW:
s such it is NOT RECOMMENDED that minimal ESP implementation supports TFC
"""
</mglt>


> Section 6:
> - More concise language/guidance on minimal ESP is required, e.g. “it is
> not
> expected to be part of minimal” needs to be stronger.  So, Next Header is
> mandatory, so guidance is that the field is there…..but is the
> recommendation
> for “minimal ESP” be that it can ignore the field?
>
> <mglt>
The Next Header is a mandatory field, so the minimal ESP needs to support
it, which support the ability to remove "no next header packet". I am
unsure what needs to be added to the text as it specifies:

"""
the Next Header is a mandatory 8 bits field in the packet [...]
"""
and
"""
[...] a minimal ESP implementation MUST discard dummy packets.
"""
I understand that the etxt needed to be more concise. Here are two
sentences I changed. Let me know if there are other I am missing.


OLD:
Next header is intended to specify the data contained in the payload as
well as dummy packet, [...]

NEW:
Next header specifies the data contained in the payload as well as dummy
packet

OLD:
it is not expected to be part of a minimal implementation of ESP.

NEW:
As a result, it SHOULD NOT be part of a minimal implementation of ESP


I am a bit reluctant saying that a minimal ESP SHOULD NOT send dummy packet
as RFC4303 mentions:

"""

A transmitter MUST be capable of
   generating dummy packets marked with this value in the next protocol

"""
</mglt>

> Section 7:
> - Do you mean authentication only w/no encryption?
>
> <mglt>
considering the previous comments as well, here is the new text I propose:

OLD:
As detailed in <xref target="sec-encr"/> we recommend using authentication,
the ICV field is expected to be present that is to say with a size
different from zero.
This makes it a mandatory field which size is defined by the security
recommendations only.

NEW:
As detailed in RFC8221 authentication or authenticated encryption are
RECOMMENDED and as such the ICV field MUST be present with a size different
from zero.
It length is defined by the security recommendations only.
</mglt>

Section 8:
> This section starts with eluding that guidelines for cipher selection
> criteria
> are provided, but as I read the list they are more considerations than
> they are
> guidelines?

<mglt>
Yes, I did not want to duplicate the cryptographic recommendations listed
in RFC8221 - which includes some IoT specific recommendations. I agree that
the section may be considered as guidelines but it seems ESP is a bit
decoupled from the cryptography used.
</mglt>


> - Currently, the ciphers that provide confidentiality always
> include authentication, so not sure the motivation for the last sentence?

 <mglt>
If the last sentence is
"""
Recommendations are provided for standard nodes as well as constrained
nodes.
"""

The intention was to mention that the recommendations do not necessarily
apply to a constrained environment. I agree it does not appear to be
essential, so I removed it.

</mglt>

> -
> Resilience to nonce reuse goes to the SN considerations as well (see my
> comments for Section 4).

<mglt>
----
ISSUE 2
---
I think I misunderstood your comment in both places so I leave it open.
</mglt>

> Another recommendation here is to also suggest that
> the provisioned key (and key should be clarified as “pre-shared key”)
> should
> also be updated with some regularity to address this issue (as in the rekey
> mechanism could lie in the management plane that provisions these keys).
>
<mglt>
Though we do not mention "pre-shared" keys, I am wondering if the text in
the security consideration does not address your purpose:

"""
<t>It is RECOMMENDED to use ESP in conjunction of key management protocols
such as for example IKEv2 <xref target="RFC7296"/> or minimal IKEv2 <xref
target="RFC7815"/>.
Such mechanisms are responsible to negotiate fresh session keys as well as
prevent a session key being use beyond its lifetime.

When such mechanisms cannot be implemented and the session key is, for
example, provisioned, the nodes MUST ensure that keys are not used beyond
their lifetime and that the appropriated use of the key remains across
reboots - e.g. conditions on counters and nonces remains valid.
</t>
"""
</mglt>

> Currently RFC8452 is not cited as negotiated ciphers in RFC 8221, so
> considerations for 96bit nonce which doesn’t fit into the ESP header, so
> while
> a general alternative not sure how you would apply it to ESP unless
> changes are
> made?

<mglt>
---
ISSUE 3
---
This is correct that AES-GCM-SIV was not mentioned in RFC8221, and I
mentioned it as an example. Now, it seems more problematic to have an
example of a cipher suite that does not work for ESP.
I am balanced between indicating that its support is not defined with ESP
so the reader still has a reference to an example of such a cipher suite.

I will raise this issue to the WG, but currently the text is as follows:

"""
When the key is likely to be re-used across reboots, it is RECOMMENDED to
consider transforms that are nonce misuse
resistant such as AES-GCM-SIV for example<xref target="RFC8452"/>. Note
however that AES-GCM-SIV has not yet been defined for ESP.
"""
</mglt>

> - What is the point driven in “interoperability”?  Is it that constrained
> devices may have limited interoperability given that they may not support
> all
> ciphers in RFC 8221?

<mglt>
It is more that what the other nodes supports needs to be considered in the
selection of the cipher suite. While RFC 8221 ensures smooth transition,
contrainted devices have less interoperability requirements.
</mglt>


> - Similarly, for the power consumption and cipher suite
> complexity; is the point that ciphers are chosen based on the constraints
> (physical, computational and memory) of the device?
>
> <mglt>
yes.
</mglt>

> Nits:
> General throughout the draft:   “constraint devices” should be “constrained
> devices”.
>
> <mglt>
thanks. I changed them all.
</mglt>

> Abstract:
>  - Last sentence of first paragraph first clause is awkward “Constrains
> include
>  among other limiting….”
> Perhaps you mean “Some constraints include limiting the…”
>
<mglt>
done. thanks.
</mglt>

>  - Some qualification of “what is required from RFC 4303” is required….
> Perhaps you mean “the minimally required set of functions and states from
> RFC
> 4303 to achieve compliance and interoperability”? My suggestion may be to
> just
> remove this 2nd paragraph as its covered in the 3rd (though I think noting
> interoperability should be there too).
>
<mglt>
I agree. done.
</mglt>

>  - I would think that there would be a strong issue if there are conflicts
> with
>  RFC 4303?! So would suggest to remove that sentence or
> Only that the RFC 4303 remains the authoritative spec to detail full
> details of
> ESP.
>
> <mglt>
done. thanks
</mglt>

> Section 2:
>  - “constraint devices” should be “constrained devices”
>
> Section 8:
> - For “Security”, suggest…”The chosen encryption algorithm MUST NOT be
> known to
> be vulnerable or weak”
>
> <mglt>
done. thanks.
</mglt>

>
>
> _______________________________________________
> Lwip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lwip
>


-- 
Daniel Migault
Ericsson