On Thu, 6 Apr 2023 12:45:25 +0200 Matthieu Baerts wrote: > The modification in the kernel looks good to me. But I don't know how to > make sure this will not have any impact on MPTCP on the userspace side, > e.g. somewhere before calling the socket syscall, a check could be done > to restrict the protocol number to IPPROTO_MAX and then breaking MPTCP > support. Then again any code which stores the ipproto in an unsigned char will be broken. A perfect solution is unlikely to exist. > Is it not safer to expose something new to userspace, something > dedicated to what can be visible on the wire? > > Or recommend userspace programs to limit to lower than IPPROTO_RAW > because this number is marked as "reserved" by the IANA anyway [1]? > > Or define something new linked to UINT8_MAX because the layer 4 protocol > field in IP headers is limited to 8 bits? > This limit is not supposed to be directly linked to the one of the enum > you modified. I think we could even say it works "by accident" because > "IPPROTO_RAW" is 255. But OK "IPPROTO_RAW" is there from the "beginning" > [2] :) I'm not an expert but Pablo's patch seems reasonable to me TBH. Maybe I'm missing some extra MPTCP specific context?
