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

[Daniel Migault <[e-mail]>]

Hi,

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

Yours,
Daniel

On Tue, Sep 4, 2018 at 4:07 AM Mohit Sethi <[e-mail]>
wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>