Hi, I am wondering what is currently the status of the draft. Feel free to let me know if I something is expected on my side.
Yours, Daniel On Thu, Oct 25, 2018 at 3:05 AM Mohit Sethi M <[email protected]> wrote: > 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 >
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
