Message ID | 1577210148-7328-1-git-send-email-tom@herbertland.com |
---|---|
Headers | show |
Series | ipv6: Extension header infrastructure | expand |
From: Tom Herbert <tom@herbertland.com> Date: Tue, 24 Dec 2019 09:55:39 -0800 > This patchset improves the IPv6 extension header infrastructure > to make extension headers more usable and scalable. > > - Reorganize extension header files to separate out common > API components > - Create common TLV handler that will can be used in other use > cases (e.g. segment routing TLVs, UDP options) > - Allow registration of TLV handlers > - Elaborate on the TLV tables to include more characteristics > - Add a netlink interface to set TLV parameters (such as > alignment requirements, authorization to send, etc.) > - Enhance validation of TLVs being sent. Validation is strict > (unless overridden by admin) following that sending clause > of the robustness principle > - Allow non-privileged users to set Hop-by-Hop and Destination > Options if authorized by the admin I see no explanation as to why we want to do this, nor why any of this is desirable at all or at any level. So as in the past, I will keep pushing back on this series because I see no real well defined, reasonable, impetus for it. Sorry.
On Wed, Dec 25, 2019 at 4:19 PM David Miller <davem@davemloft.net> wrote: > > From: Tom Herbert <tom@herbertland.com> > Date: Tue, 24 Dec 2019 09:55:39 -0800 > > > This patchset improves the IPv6 extension header infrastructure > > to make extension headers more usable and scalable. > > > > - Reorganize extension header files to separate out common > > API components > > - Create common TLV handler that will can be used in other use > > cases (e.g. segment routing TLVs, UDP options) > > - Allow registration of TLV handlers > > - Elaborate on the TLV tables to include more characteristics > > - Add a netlink interface to set TLV parameters (such as > > alignment requirements, authorization to send, etc.) > > - Enhance validation of TLVs being sent. Validation is strict > > (unless overridden by admin) following that sending clause > > of the robustness principle > > - Allow non-privileged users to set Hop-by-Hop and Destination > > Options if authorized by the admin > > I see no explanation as to why we want to do this, nor why any of this > is desirable at all or at any level. > > So as in the past, I will keep pushing back on this series because I > see no real well defined, reasonable, impetus for it. > Hi Dave, The fundamental rationale here is to make various TLVs, in particular Hop-by-Hop and Destination options, usable, robust, scalable, and extensible to support emerging functionality. Specifically, this patch set: 1) Allow modules to register support for Hop-by-Hop and Destination options. This is useful for development and deployment of new options. 2) Allow non-privileged users to set Hop-by-Hop and Destination options for their packets or connections. This is especially useful for options like Path MTU and IOAM options where the information in the options is both sourced and synced by the application. The alternative to this would be to create more side interfaces so that the option can be enabled via the kernel-- such side interfaces would be overkill IMO. 3) In conjunction with #2, validation of the options being set by an application is done. The validation for non-privileged users is purposely strict, but even in the case of privileged user validation is useful to disallow allow application from sending gibberish (for instance, now a TLV could be created with a length exceeding the bound of the extension header). 4) Consolidate various TLV mechanisms. Segment routing should be able to use the same TLV parsing function, as should UDP options when they come into the kernel. 5) Option lookup on receive is O(1) instead of list scan. Subsequent patch set will include: 6) Allow setting specific (Hop-by-Hop and Destination) options on a socket. This would also allow some options to be set by application and some might be set by kernel. 7) Allow options processing to be done in the context of a socket. This will be useful for FAST, PMTU options. 8) Allow experimental IPv6 options in the same way that experimental TCP options are allowed. 9) Support a robust means extension header insertion. Extension header insertion is a controversial mechanism that some router vendors are insisting upon (see ongoing discussion in 6man list). The way they are currently doing it breaks the stack (particularly ICMP and the way networks are debug), with proper support I believe we can at least mitigate the effects of the problems they are creating. 10) Support IPv4 extension headers. This again attempts to address some horrendous and completely non-robust hacks that are currently being perpetuated by some router vendors. For instance, some middlebox implementations are currently overwriting TCP or UDP payload with their own data with the assumption that a peer device will restore correct data. If they ever miss fixing up the payload then we now have systematic silent data corruption (IMO, this very dangerous in a large scale deployment!). We can offer a better approach... Tom
From: Tom Herbert <tom@herbertland.com> Date: Thu, 26 Dec 2019 13:12:11 -0800 > The fundamental rationale here is to make various TLVs, in particular ... Don't tell me, put it in the introductory commit message.