Re: [Lwip] [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued"

Paul Wouters <> Fri, 31 August 2018 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85342130E51; Fri, 31 Aug 2018 09:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wnLc9ZiROry8; Fri, 31 Aug 2018 09:50:40 -0700 (PDT)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10535127148; Fri, 31 Aug 2018 09:50:40 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 42252h59VBz5C2; Fri, 31 Aug 2018 18:50:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1535734236; bh=kVf1RGFe62atPlwVa03ej8ICMiNALTOG0TF2HGoPX1Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KPxrkoUH8+wAXfkxz9b/ezY4qUhdTuhFR15YloewiZD8vEhvBMrpZ6nxaXP+p5JIh PV/VK9YwQdBLUvNt83ZQLxgV3blpEox0eM/vlHkuaqwiQtbGcCMDVZVPoD91wkLiqa 5VZ19qNhsN5mduWKSAoBTOclneQoJuUqIgmjlbyM=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id GeGC4v1GYg76; Fri, 31 Aug 2018 18:50:33 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Fri, 31 Aug 2018 18:50:32 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 594F95E2A5B; Fri, 31 Aug 2018 12:50:31 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 594F95E2A5B
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D0FF402E52A; Fri, 31 Aug 2018 12:50:31 -0400 (EDT)
Date: Fri, 31 Aug 2018 12:50:31 -0400
From: Paul Wouters <>
To: Tero Kivinen <>
cc: Heinrich Singh <>,,,
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <>
Subject: Re: [Lwip] [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued"
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Aug 2018 16:50:42 -0000

On Fri, 31 Aug 2018, Tero Kivinen wrote:

> There is no requirement for SPI to be random and originally it was
> written that way so implementations can use whatever method to
> allocate SPIs they like.

However, the randomized SPIs does give us some security, as we saw in
the SLOTH attack, that was only stopped because of the effort of 2^77
to break. If we used predictable SPIs for IKE, then IKE would have
fallen to the SLOTH attack as well.

Although in this case, I guess we are talking about ESP/AH SPIs. There
is still benefits in randomness, even if it is not cryptographically
random. Just to ensure the same SPIs aren't re-used too quickly and
get confused. The document does correctly point out not to use SPIs
below 256.

> Adding requirement that SPI needs to be random would be modifying the
> base ESP, and is not in the scope of draft trying to define minimal
> ESP. Saying that in contrained devices which have very few SPIs the
> SPIs can be allocated using some other method than random is in scope
> of the this draft.


> On the other hand sender is REQUIRED to send sequence numbers in such
> way they are monotonically incrementing (not necessarely by one), and
> if it has any kind of other monotonically incrementing counter like
> clock, it can use that to generate the sequence numbers and get rid of
> the requirement to store outgoing sequence number to the flash.

Wouldn't not incrementing by one screw up the windoz sizes of receiving
ends? Eg if they received #64, they might accept 65-128 so receiving 300
might just make them do more work or effectively have no window?

> I have not actually never seen anybody sending dummy packets or TFC
> padding packets in any implementations.

Yup. Linux supports it. With libreswan you can configure tfc= with a
value of zero meaning pad to MTU. We haven't yet enabled this by default,
since there are reasons for and against it. It's much better for privacy
obviusly, but if this is going of mobile data, you are paying for the

> not even sure which implementation support for sending dummy packets.

That I don't know either. although there are already so many "dumb" DPD
packets, we sort of have this already over port 4500 :)

> So as those are not really used in non-constrained devices

Hmm, I guess the Lantronix Xport Pro does not count as constrained?
Because it does run Linux and libreswan in 8MB SDRAM with NOMMU :)

I still have to read the full document before I decide if I am in favour
of adopting or not.