Hi Paul, Heinrich and Tero, The authors have updated the draft based on the feedback received:
https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/ Please let us know whether you still have objections to this being adopted as a WG document. --Mohit On 8/31/18 7:50 PM, Paul Wouters wrote: > 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 _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
