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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
