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

[Mohit Sethi <[e-mail]>]

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.