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

From: Heinrich Singh <[email-masked]>
Date: Thu, 23 Aug 2018 21:32:03 +0300

Hello IETF,

I am new to LWIP/IPSEC. I read draft-mglt-lwig-minimal-esp. Here is my
summary:

   1. Don't use random SPI because getting randomness on small devices is
   expensive. This will of course leak privacy. If a vendor/app uses fixed SPI
   for his devices, then someone on the network can find out info of
   vendor/app. Also, why a device can generate random number for doing IKEv2,
   nonces etc. but not for generating SPI?
   2. Storing sequence numbers is difficult so devices can use time.
   Getting time on small devices is actually much harder. Also is there some
   hard info that reading time is cheaper than reading sequence number from
   memory? I can also look at packets much later and tell when you sent a
   packet.
   3. Don't use Traffic Flow Confidentiality again loosing privacy.
   4. Don't use dummy packets again loosing privacy.
   5. Reference rfc 8221 for IoT related crypto suites.

I don't know why IETF would publish this document when they have rfc 6973.
I want to see some actual performance from a real ESP implementation where
privacy is protected and energy is saved by tweaking the TFC and how often
dummy packet is sent.

Ciao
Heinrich

---

From: Daniel Migault <[email-masked]>
Date: Wed, 29 Aug 2018 12:17:20 -0400

Hi Heinrich,

Thank you for reviewing the draft. Please find my response inline. I
believe your concerns are addressed in the draft within the scope of the
draft. The work you are mostly looking at would be an efficient TFC / dummy
packet policy. This would more probably be in scope of ipsecme WG.

Yours,
Daniel

On Thu, Aug 23, 2018 at 2:32 PM, Heinrich Singh <[email-masked]>
wrote:

>    vendor/app.
> <mglt>
This is correct and I believe this statement is provided in the draft. Is
there, in your opinion, anything we should add in the text below:

   The use of a limited number of fix SPI also come with security or
   privacy drawbacks.  Typically, a passive attacker may derive
   information such as the number of constrained devices connecting the
   remote peer, and in conjunction with data rate, the attacker may
   eventually determine the application the constrained device is
   associated to.  In addition, if the fix value SPI is fixed by a
   manufacturer or by some software application, the SPI may leak in an
   obvious way the type of sensor, the application involved or the model
   of the constrained device.  As a result, the use of a unpredictable
   SPI is preferred to provide better privacy.

   As far as security is concerned, revealing the type of application or
   model of the constrained device could be used to identify the
   vulnerabilities the constrained device is subject to.  This is
   especially sensitive for constrained device where patches or software
   updates will be challenging to operate.  As a result, these devices
   may remain vulnerable for relatively long period.  In addition,
   predictable SPI enable an attacker to forge packets with a valid SPI.
   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.

</mglt>
 Also, why a device can generate random number for doing IKEv2, nonces etc.
but not for generating SPI?

<mglt>

I am reading your text as if the draft were recommending the use of non
random SPI, while you would expect the draft to recommend a random
generation of the SPI. I think the draft address your comment by
recommending a random generation of the SPI with the text below:

   It is RECOMMENDED to randomly generate the SPI indexing each inbound
   session.  A random generation provides a stateless way to generate
   the SPIs, while keeping the probability of collision between SPIs
   relatively low.  In case of collision, the SPI is simply re-
   generated.

We could have hardly go further for example by saying SPI MUST be randomly
generated as this is not required by RFC4303. Such requirement woudl have
been out of scope of the draft as the purpose of the draft is not to update
the standard ESP and become a replacement of RFC4303. instead, its purpose
is to implement a minimal version of RFC 4303. SPI randomness is not
required by RFC4303, so this document cannot mandate SPI generation to be
random.

The draft also clearly stated that non compromise on random generator
should mad for random used for cryptographic purpose. This is not the case
for SPI, and some device may, when necessary, use this to save cycles.

</mglt>

>
>    1. Storing sequence numbers is difficult so devices can use time.
> <mglt>
We received this example from people following IEEE802.15. It would be good
you share your information why reading time is much harder, so the
discussion can happen on the mailing list. From my perspective the main
idea was to explain that you could take advantage of an already existing
"always increasing" function set on your device. Typically, the time is
shared across the device and can be used by ALL session, instead of having
multiple Sequence numbers.

As a side note, if your cases does not fit this, you do not necessarily
need to follow this implementation ;-). However, I am happy if your are
proposing text to make this more accurate.
</mglt>

>
>    1. Don't use Traffic Flow Confidentiality again loosing privacy.
>
> <mglt>
I believe this is what the current version of the draft says. However, as
mentioned before, this draft is not updating RFC4303 and as such cannot
make this feature mandatory.

In addition, TFC is *really* not the kind of feature we expect for a
minimal implementation in constrint devices. Typically it consists in
adding extra bytes while this is precisely the tasks that consumes the more
resource for most of the constraint devices. In addition, managing TFC to
avoid creating a new pattern is neither trivial, nor widely used. It woudl
be mostly based on statistics, and such functionalities are not expected to
be found on constraint device. It is not obvious also that such option
could introduce specific patterns which could also loose privacy.

Again if you find the text misleading, I am happy you propose text to
improve it.

   ESP [RFC4303 <https://tools.ietf.org/html/rfc4303>] also provides
Traffic Flow Confidentiality (TFC) as a
   way to perform padding to hide traffic characteristics, which differs
   from respecting a 32 bit alignment.  TFC is not mandatory and MUST be
   negotiated with the SA management protocol.  As a result, TFC is not
   expected to be supported by a minimal ESP implementation.  On the
   other hand, disabling TFC should be carefully measured and understood
   as it exposes the node to traffic shaping.  This could expose the
   application as well as the devices used to a passive monitoring
   attacker.  Such information could be used by the attacker in case a
   vulnerability is disclosed on the specific device.  In addition, some
   application use - such as health applications - may also reveal
   important privacy oriented informations.

   Some constrained nodes that have limited battery life time may also
   prefer avoiding sending extra padding bytes.  However the same nodes
   may also be very specific to an application and device.  As a result,
   they are also likely to be the main target for traffic shaping.  In
   most cases, the payload carried by these nodes is quite small, and
   the standard padding mechanism may also be used as an alternative to
   TFC, with a sufficient trade off between the require energy to send
   additional payload and the exposure to traffic shaping attacks.

</mglt>

>
>    1. Don't use dummy packets again loosing privacy.
>
> <mglt>
The draft does not prevent the use of dummy packets. Instead implementation
must be able to discard received dummy packet.. I believe the issue you are
raising is that RECOMMEND be changed in MUST. Thanks for raising this I
will update the draft. What the draft says is rather setting a widely used
policies for generating dummy packets, i.e. that is generating none. I do
not think we expect more from a minimal implementation.

Similarly, handling dummy packet is not obvious, and maybe not expected to
be treated correctly by constrained devices.  The draft also mention the
privacy issues associated to not generating dummy packets. Is there any
text you woudl like to propose ?

   The ability to generate and receive dummy packet is required by
   [RFC4303 <https://tools.ietf.org/html/rfc4303>].  For
interoperability, it is RECOMMENDED a minimal ESP
   implementation discards dummy packets.  Note that such recommendation
   only applies for nodes receiving packets, and that nodes designed to
   only send data may not implement this capability.

   As the generation of dummy packets is subject to local management and
   based on a per-SA basis, a minimal ESP implementation may not
   generate such dummy packet.  More especially, in constrained
   environments sending dummy packets may have too much impact on the
   device life time, and so may be avoided.  On the other hand,
   constrained nodes may be dedicated to specific applications, in which
   case, traffic pattern may expose the application or the type of node.
   For these nodes, not sending dummy packet may have some privacy
   implication that needs to be measured.

</mglt>

>
>    1. Reference rfc 8221 for IoT related crypto suites.
>
> <mglt>
The draft provide the reference at least 5 times.
</mglt>

>    1.

<mglt>
I agree that would be an interesting topic, but outside teh scope of
defining a minimal implementation for the current ESP. I believe the work
you are expecting is the definition of an efficient TFC / dummy packet
policies. This is currently more a research project. This may be a link of
interest:
https://www.researchgate.net/publication/224720331_Traffic_masking_in_IPsec_architecture_and_implementation

</mglt>

>
> Ciao
> Heinrich
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Heinrich Singh <[email-masked]>
Date: Fri, 31 Aug 2018 10:12:05 +0300

Hello Daniel,

Text saying that you would loose some privacy by using fixed number of SPI
does not absolve your responsibility. It should not recommend that.

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. 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.

What you mean implementations must discard dummy packets? Even
non-constrained implementations must discard dummy packets so what is new
here?

Okay. the paper you send me is for linux kernel, not for constrained device.

Ciao
Heinrich

On Wed, 29 Aug 2018 at 19:17, Daniel Migault <[email-masked]>
wrote:

>>    1. Don't use random SPI because getting randomness on small devices
>>    is expensive. This will of course leak privacy. If a vendor/app uses fixed
>>    SPI for his devices, then someone on the network can find out info of
>>    vendor/app.
>>
>> <mglt>
>  Also, why a device can generate random number for doing IKEv2, nonces
> etc. but not for generating SPI?
>
> <mglt>
>
> We received this example from people following IEEE802.15. It would be
> good you share your information why reading time is much harder, so the
>    ESP [RFC4303 <https://tools.ietf.org/html/rfc4303>] also provides Traffic Flow Confidentiality (TFC) as a
> The draft does not prevent the use of dummy packets. Instead
> implementation must be able to discard received dummy packet.. I believe
> the issue you are raising is that RECOMMEND be changed in MUST. Thanks for
> raising this I will update the draft. What the draft says is rather setting
> a widely used policies for generating dummy packets, i.e. that is
> generating none. I do not think we expect more from a minimal
> implementation.
>
>    [RFC4303 <https://tools.ietf.org/html/rfc4303>].  For interoperability, it is RECOMMENDED a minimal ESP

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 31 Aug 2018 16:41:23 +0300

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. 

> 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. 

> 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. 
-- 
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Fri, 31 Aug 2018 09:47:17 -0400

Hi Heinrich,

Thanks for your responses, please see my comments inline.

Yours,
Daniel

> does not absolve your responsibility. It should not recommend that.
I got your point. Thanks. While fix SPI is permitted by  RFC4303, and the
document implicitly described it as an non recommended alternative, you
would like the guidance to be more explicit.  We can add text stating that
because of privacy, fix SPI is not recommended for generic purpose
implementations.

I believe that the point fo this document is to provide some implementation
guidance for specific implementation to implement ESP optimized for
specific use cases while remaining compatible to the standard ESP. As a
result, guidance may go beyond the once fits all use cases. Of course the
document should clarify the limitations.
</mglt>

> still need to store time to flash in-case there is need for sync after
<mglt>
First all of all, the draft clearly stated that the use of time is an
alternative ways which is not the most usual implemented mechanism. I
believe that similarly as the previous section, we could explicitly mention
that the recommended way to generate SSN is to increment it. We can also
add text the explicit text regarding the additional constraints, and
specify that such way is not recommended for a generic purpose
implementation.

Similarly we should clarify, the limitations for this specific mechanism,
so the mechanism could be chosen only when appropriated. Again, constraint
device have different constraints, and there specificities may allo one or
the other mechanisms to be used. There are many use cases where devices
sends informations are regular time interval and that the lost of a packet
will have a limited impact.

However I am happy you raises the discussion that can continue on the list.
Thank you.
</mglt>

> non-constrained implementations must discard dummy packets so what is new
I meant packet with next header value set to 59.
</mglt>

> <mglt>
Thisis correct. I mentioned it as maybe a starting point for the specific
topic your mentioned.
</mglt>

>> We could have hardly go further for example by saying SPI MUST be
>> randomly generated as this is not required by RFC4303. Such requirement
>> woudl have been out of scope of the draft as the purpose of the draft is
>> not to update the standard ESP and become a replacement of RFC4303.
>> instead, its purpose is to implement a minimal version of RFC 4303. SPI
>> randomness is not required by RFC4303, so this document cannot mandate SPI
>> generation to be random.
>>
>> Similarly, handling dummy packet is not obvious, and maybe not expected
>> to be treated correctly by constrained devices.  The draft also mention the
>> I want to see some actual performance from a real ESP implementation
>> where privacy is protected and energy is saved by tweaking the TFC and how
>> often dummy packet is sent.
>>
>> <mglt>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Aug 2018 11:50:21 -0400

Tero Kivinen <[email-masked]> wrote:
    > 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.

    > deliver is not possible, thus it can just keep window size to 1.

For instance, if one has a single CoAP session active, then there will be in
essence only one packet in flight in either direction, so maybe there is no
re-ordering possible.  (Yes, there can be retransmits)

    > the requirement to store outgoing sequence number to the flash.

I agree that this would work well.

    > 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.

Good point, and this makes the packet the same size as well, and uses less code.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters <[email-masked]>
Date: Fri, 31 Aug 2018 12:50:31 -0400 (EDT)

On Fri, 31 Aug 2018, Tero Kivinen wrote:

> 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.

https://access.redhat.com/blogs/product-security/posts/sloth

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.

> SPIs can be allocated using some other method than random is in scope

Agreed.

> 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?

> 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
padding.

> 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.

Paul