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

[Daniel Migault <[e-mail]>]

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 <[e-mail]>
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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lwip
>
> _______________________________________________
> Lwip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lwip
>