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

"Valery Smyslov" <smyslov.ietf@gmail.com> Tue, 03 December 2019 13:08 UTC

Return-Path: <smyslov.ietf@gmail.com>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1857312002E; Tue, 3 Dec 2019 05:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 nrqyFOA_e0il; Tue, 3 Dec 2019 05:08:14 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 DBED1120019; Tue, 3 Dec 2019 05:08:13 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id j6so3762608lja.2; Tue, 03 Dec 2019 05:08:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=QVkhHup+jtaPqOrVxW6x+Ebbq+ApRGt8wrQ0yC53Bas=; b=LpioZkYoOnTGchXpDgpeIG1g0qkezYHGZ2zmwFRefZyVQLJkiqaHtfCjqgymhlCSLO jwa7tGxDs8zTRvHQ7rHvmYwQo6HxX2KL1Qs5mXNe+6hHrU1bouBBX3I/zyOtZUc5ewa3 3a7+EHiDodLMacbProld6Xpj6kvT7Bo1rO2v582Jh4aF/qhCOzXIBCaqgVGxUgHrZNgK 7h5CUxM3lMjbxzd/e3nuazJqVme5kc3wQ4j4C2tPjnvPK0UBHjeGgql+dIRKkcVAAeXO 7yXonqpSPJ3kNTmG14aM1HENfrTULQkEoOWzWcu/nhGDm09/PjQtvYulibBlT3EL9BQ9 XEPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=QVkhHup+jtaPqOrVxW6x+Ebbq+ApRGt8wrQ0yC53Bas=; b=B1rRFio5AgBPyq/C9y6FRFGByfqiGuUDG8csTO0sSVrSBic6f977iQXTvtDzyMRzFH R5Fd3ZPrLNXgBPM0hRmLOrMhMCS5DtaAXAZu2H/mpFxD2rqComMVvuczHQYG7YH1coGz PXevHm3H7vl3roTa4bgaZfvsxV8s0Hw6es6eJYp/nl/tTVOfw4ctBnM1wqd6gH8RGZOK c84INt1nRXGnguYthhT5rkhmnVqHdkdG+di0qikceKeHpE7kHHOWdAw3nVJnwjAyIYT2 EX2JUOTH3elNTVV78PDY7WriP1vczXH2QB2X0VYlwAAHmxYibWuotOOOfkX0BqYuciT8 xexQ==
X-Gm-Message-State: APjAAAXFZSjICCMh+3wr2ksMwK3xXDayxd6T1UYWOZc3+OqReGIve6WV VYweHEqZuyf0J5np6kNgbj/dHLiK
X-Google-Smtp-Source: APXvYqw9d8+0xKGzRVrDlgQdRh4SjtrOzg9zTer8ZHx8QjxqE7m1U9+kOEimzkFqL6eL0SSV+abXOg==
X-Received: by 2002:a2e:809a:: with SMTP id i26mr2504753ljg.108.1575378491800; Tue, 03 Dec 2019 05:08:11 -0800 (PST)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id n83sm1290106lfd.70.2019.12.03.05.08.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Dec 2019 05:08:11 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Daniel Migault' <mglt.ietf@gmail.com>, 'Tobias Guggemos' <tobias.guggemos@outlook.com>
Cc: lwip@ietf.org, IPsecME WG <ipsec@ietf.org>
Date: Tue, 03 Dec 2019 16:08:12 +0300
Message-ID: <060501d5a9da$b8552490$28ff6db0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdWppfOpIKBZp+0/S/GeseFeC790Mw==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/p1i4hZBjn7PD3ksS9kh8C0ouUOU>
Subject: [Lwip] Review of draft-ietf-lwig-minimal-esp-00
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2019 13:08:16 -0000

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.