Re: [Lwip] Review of draft-ietf-lwig-minimal-esp-00

[Daniel Migault <[e-mail]>]

Thank you Valery for the detailed review. That is really much appreciated.
We will update the document accordingly by the next few weeks also
considering the feed backs from Scott.

Yours,
Daniel

On Tue, Dec 3, 2019 at 8:08 AM Valery Smyslov <[e-mail]>
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).
>
> 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).
>
>
> 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.
>
>    When used indoor, the privacy information is stored in the encrypted
>    data and as such does not leak privacy.
>
> I cannot parse this :-)
>
>    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.
>
>    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).
>
> 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).
>
> 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.
>
> 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 :-)
>
>
> Nits:
> Throughout the text:
> s/fix SPI/fixed SPI
> s/constraint node/constrained node
> s/algorythm/algorithm
>
> Section 2:
>
> s/IPsec suite protocol/IPsec protocol suite
>
> 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
>
>    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
>
> 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
>
> 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
>
>        Note that it
>        is not because a encryption algorithm transform is widely
>        deployed that is secured.
>
> s/a/an
>
> Regards,
> Valery Smyslov.
>
>
>