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

[Paul Wouters <[e-mail]>]

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