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

[Tero Kivinen <[e-mail]>]

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. 
-- 
[e-mail]