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

Daniel Migault <> Tue, 04 September 2018 11:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3A16130DCA; Tue, 4 Sep 2018 04:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wbs7n1GBFCVt; Tue, 4 Sep 2018 04:55:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D385128CF2; Tue, 4 Sep 2018 04:55:57 -0700 (PDT)
Received: by with SMTP id f1-v6so2872772ljc.9; Tue, 04 Sep 2018 04:55:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=49m4uNTnCvgLM50IpfJzAR3g5uAluw4azEooGw5jahQ=; b=i7r12G6QaaGhq6LWLeRz6Zg2V618QQ9JVUuLWvPFYlEFeflxrzvdeF1QZC73gcX012 9KsnKKAzbEqobzJdkYRcKcK5BAQSkhIGZicx79T1Z7yyqDiYhEZgwgNgh3Jp8LnUXk9I Sr3sbZgCBAs9orHXVahAhjlAGY5A2OquzajagT4NR4B4Rx8t82n/o0mtg+pNKuli5JQ3 zeHKi8dOX13vc94+OxhZ9a/icQsdq52YaZcJMn3OQDHvZ11vblm9HBadfIKd/NvSEg// VxSuYaRB6LNXSWgQ+Osyirh/wcv24jYU8r2yRDNbJjMHOuss/POtWl7MF/uONtKHnuty dhuA==
X-Gm-Message-State: APzg51Az38SqMORdipsoATIMJw1QkH+QHiEGmKTm195YJ8ThXN4ArsJw i7g/4mAwj7YKpQFBDDyzebc60y4OUCOhBecKZZE=
X-Google-Smtp-Source: ANB0VdZfbQDW+w5LkKVt9/4e79ouEDbKanyvKmfA/GLRvr1N8uyyTRTrEWqIWu2fHCPFQEeL63J6ijNoVwnMr+5YxQQ=
X-Received: by 2002:a2e:9c82:: with SMTP id x2-v6mr14759276lji.131.1536062154008; Tue, 04 Sep 2018 04:55:54 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Tue, 04 Sep 2018 07:55:42 -0400
Message-ID: <>
To: Mohit Sethi <>
Cc: Tero Kivinen <>, Heinrich Singh <>, IPsecME WG <>,
Content-Type: multipart/alternative; boundary="0000000000000aeec205750a57e5"
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: Tue, 04 Sep 2018 11:56:00 -0000


Just to mention that of course, the draft will be updated to reflect the
discussions / clarifications raised on the mailing list.


On Tue, Sep 4, 2018 at 4:07 AM Mohit Sethi <>

> Hi Tero,
> You raise some very interesting points here.
> I personally think that the draft can benefit from more information
> about existing implementations of ESP. For example, documenting the fact
> that many implementations do not send dummy packets or which
> implementations use TFC. Adding specific example of  802.15.4 TSCH
> networks and how synchronized time is available would also be helpful.
> Of course, this could be done before or after its adoption.
> --Mohit
> On 08/31/2018 04:41 PM, Tero Kivinen wrote:
> > Heinrich Singh writes:
> >> Text saying that you would loose some privacy by using fixed number
> >> of SPI does not absolve your responsibility. It should not recommend
> >> that.
> > 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. For example they can use index to the SPI
> > table or whatever instead of allocating random SPI, or they could even
> > use pointer to the SPI structure in memory as SPI value (would of
> > course need some kind of checks that address is in area allocated for
> > SPIs and is aligned properly).
> >
> > 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.
> >
> > Also most of the constrained devices do not care about privacy as they
> > have fixed hardware address, stable IPv6 address and are not
> > associated with any person. Sensor sending wind speed, or temperature
> > to the cloud service does not have privacy requirements, sensors
> > sending temperature inside your house might have (as it might leak out
> > information whether you are home or not), but even in that case the
> > fact that it is your sensor sending information every 60 seconds does
> > not, only the data inside.
> >
> > Privacy requirements are not something that are always there, they
> > always depend heavily about what you do with the protocol. I.e., in
> > some cases the IP addresses, hardware addresses, SPIs etc need to be
> > protected against tracking, but in many cases they do not need to be.
> >
> > This document gives recommendation that in some cases it might be good
> > idea to use fixed SPI as it might make implementations smaller. I.e.,
> > if the option is either not to use IPsec at all, as it is too big, or
> > to use IPsec with fixed SPI and other limitations that make it small,
> > I think the option with IPsec is better.
> >
> >> I do not know 802.15. Others can also say what they feel but from my
> >> experience simple monotonic sequence numbers are more easier than
> >> having a clocks.
> > True. But for example 802.15.4 TSCH (i.e., the protocol over which
> > 6TiSCH is working) does have globally shared clock which is kept in
> > sync with everybody. So in that kind of situations using clock as
> > monotonically incrementing counter and using that as sequence number
> > might save resources in constrained device.
> >
> >> This I think is a not a good idea. Sender and receiver can easily
> >> get out of sync because your rate of sending packets is not
> >> proportional to time. The receiver would need to allow very large
> >> window. The sender would still need to store time to flash in-case
> >> there is need for sync after device reset.
> > Sequence numbers are in one direction, i.e., I need to use
> > monotonically incrementing sequence number when I send, but that
> > sequence number does not have anything to do with other ends sequence
> > number. Also window size is need only if you have out of order
> > packets, and you care about replay protection. Both of them are
> > something that might not be something that constrained device cares.
> >
> > For example it might have internal replay protection for the messages
> > it sends, so it does not need to care whether there is replays on the
> > IPsec level, thus it can drop the whole replay protection checks
> > completely. Or it might work on the environment where out of order
> > deliver is not possible, thus it can just keep window size to 1.
> >
> > Also recipient cannot know which method other end is using when
> > generating sequence numbers, so it needs to do the replay protection
> > checking using whatever method it wants. It might need to store the
> > last received sequence number to the flash if it cares about replay
> > protections, or it can simply drop replay protection completely.
> >
> > 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.
> >
> >> What you mean implementations must discard dummy packets? Even
> >> non-constrained implementations must discard dummy packets so what
> >> is new here?
> > Yes. And that quite often happens automatically as there is nobody in
> > the device that wants to get packets with that protocol number.
> >
> > I have not actually never seen anybody sending dummy packets or TFC
> > padding packets in any implementations. I guess most of them know how
> > to ignore them, but sending them is not something people do. And I am
> > not even sure which implementation support for sending dummy packets.
> > TFC is most likely supported in some implementations (libreswan at
> > least seems to support it) as it is much easier to configure, just pad
> > all packets to fixed length. When sending dummy packets configuration
> > is much more complicated, as you need to configure what kind of
> > traffic pattern you want to maintain.
> >
> > So as those are not really used in non-constrained devices, I do not
> > think there is that big different in constrained devices. Again all of
> > this depends on the environment. For example some kind of door sensor
> > might want to keep sending packets every n seconds just not to leak
> > out when the door was opened and closed, but it might just use real
> > packets instead of dummy packets. I.e., it might be configured to send
> > the door status every 30 seconds, and in that packet it tells whether
> > door is now open or closed, and whether what transitions happened
> > during last 30 seconds.
> >
> > Privacy is so hard topic to solve that it always requires you to check
> > out the actual environment and use case where the protocol is used
> > before you can decide what kind of protections are needed. There is no
> > this thing solves all issues solution there.
> _______________________________________________
> IPsec mailing list