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

From: Mohit Sethi M <[email-masked]>
Date: Thu, 25 Oct 2018 07:04:44 +0000

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-masked]
> https://www.ietf.org/mailman/listinfo/lwip