On Fri, 31 Aug 2018, Tero Kivinen wrote:
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.
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.
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.
Agreed.
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.
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?
I have not actually never seen anybody sending dummy packets or TFC 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 _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
