| 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.
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 v2: - Fix build errors from missing include file. v3: - Fix kbuild issue for ipv6_opt_hdr declared inside parameter list in ipeh.h v4: - Resubmit v5: - Fix reverse christmas tree issue v6: - Address comments from Simon Horman - Remove new EXTHDRS Kconfig symbol, just use IPV6 for now - Split out introduction of parse_error for TLV parsing loop into its own patch - Fix drop counters in HBH and destination options processing - Add extack error messages in netlink code - Added range of permissions in include/uapi/linux/ipeh.h - Check that min data length is <= max data length when setting TLV attributes v7: - Fix incorrect index in checking for nonzero padding - Use dev_net(skb->dev) in all cases of __IP6_INC_STATS for hopopts and destopts (addresses comment from Willem de Bruijin) Tom Herbert (9): ipeh: Fix destopts counters on drop ipeh: Create exthdrs_options.c and ipeh.h ipeh: Move generic EH functions to exthdrs_common.c ipeh: Generic TLV parser ipeh: Add callback to ipeh_parse_tlv to handle errors ip6tlvs: Registration of TLV handlers and parameters ip6tlvs: Add TX parameters ip6tlvs: Add netlink interface ip6tlvs: Validation of TX Destination and Hop-by-Hop options include/net/ipeh.h | 209 ++++++++ include/net/ipv6.h | 12 +- include/uapi/linux/in6.h | 6 + include/uapi/linux/ipeh.h | 53 ++ net/dccp/ipv6.c | 2 +- net/ipv6/Makefile | 3 +- net/ipv6/calipso.c | 6 +- net/ipv6/datagram.c | 51 +- net/ipv6/exthdrs.c | 514 ++----------------- net/ipv6/exthdrs_common.c | 1216 ++++++++++++++++++++++++++++++++++++++++++++ net/ipv6/exthdrs_options.c | 342 +++++++++++++ net/ipv6/ipv6_sockglue.c | 39 +- net/ipv6/raw.c | 2 +- net/ipv6/tcp_ipv6.c | 2 +- net/ipv6/udp.c | 2 +- net/l2tp/l2tp_ip6.c | 2 +- net/sctp/ipv6.c | 2 +- 17 files changed, 1942 insertions(+), 521 deletions(-) create mode 100644 include/net/ipeh.h create mode 100644 include/uapi/linux/ipeh.h create mode 100644 net/ipv6/exthdrs_common.c create mode 100644 net/ipv6/exthdrs_options.c