lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1556563576-31157-1-git-send-email-tom@quantonium.net>
Date:   Mon, 29 Apr 2019 11:46:10 -0700
From:   Tom Herbert <tom@...bertland.com>
To:     davem@...emloft.net, netdev@...r.kernel.org
Cc:     Tom Herbert <tom@...ntonium.net>
Subject: [PATCH v7 net-next 0/6] exthdrs: Make ext. headers & options useful - Part I

Extension headers are the mechanism of extensibility for the IPv6
protocol, however to date they have only seen limited deployment.
The reasons for that are because intermediate devices don't handle
them well, and there haven't really be any useful extension headers
defined. In particular, Destination and Hop-by-Hop options have
not been deployed to any extent.

The landscape may be changing as there are now a number of serious
efforts to define and deploy extension headers. In particular, a number
of uses for Hop-by-Hop Options are currently being proposed, Some of
these are from router vendors so there is hope that they might start
start to fix their brokenness. These proposals include IOAM, Path MTU,
Firewall and Service Tickets, SRv6, CRH, etc.

Assuming that IPv6 extension headers gain traction, that leaves a
noticeable gap in IPv4 support. IPv4 options have long been considered a
non-starter for deployment. An alternative being proposed is to enable
use of IPv6 options with IPv4 (draft-herbert-ipv4-eh-00).

This series of patch sets endeavours to make extension headers and
related options useful and easy to use. The following items will be
addressed:

  - Reorganize extension header files
  - 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
  - Add an API that allows individual Hop-by-Hop and Destination
    Options to be set or removed for a connected socket. The
    backend end enforces permissions on what TLVs may be set and
    merges set TLVs per following the rules in the TLV parameter table
    (for instance, TLV parameters include a preferred sending order
    that merging adheres to)
  - Add an infrastructure to allow Hop-by-Hop and Destination Options
    to be processed in the context of a connected socket
  - Support for some of the aforementioned options
  - Enable IPv4 extension headers

------

In this series:

- Create exhdrs_options.c. Move options specific processing to this
  file from exthdrs.c (for RA, Jumbo, Calipso, and HAO).
- Create exthdrs_common.c. This holds generic exthdr and TLV related
  functions that are not IPv6 specific. These functions will also be
  used with IPv4 extension headers.
- Allow modules to register TLV handlers for Destination and HBH
  options.
- Add parameters block to TLV type entries that describe characteristics
  related to the TLV. For the most part, these encode rules about
  sending each TLV (TLV alignment requirements for instance).
- Add a netlink interface to manage parameters in the TLV table.
- Add validation of HBH and Destination Options that are set on a
  socket or in ancillary data in sendmsg. The validation applies the
  rules that are encoded in the TLV parameters.
- TLV parameters includes permissions that may allow non-privileged
  users to set specific TLVs on a socket HBH options or Destination
  options. Strong validation can be enabled for this to constrain
  what the non-privileged user is able to do.

v2:

- Don't rename extension header files with IPv6 specific code before
  code for IPv4 extension headers is present
- Added patches for creating TLV parameters and validation

v3:

- Fix kbuild errors. Ensure build and operation when IPv6 is disabled.

v4:

- Remove patch that consolidated option cases in option cases in
  ip6_datagram_send_ctl per feedback

v5:

- Add signoffs.

v6:

- Fix init_module issue from kuild.
  Reported-by: kbuild test robot <lkp@...el.com>

v7:

- Create exthdrs_common.c. Use this file for for generic functions that
  apply to IPv6 and IPv4 extension headers. Don't touch exthdr_core.c
  to preserve the semantics that that file contains functions that are
  needed when IPv6 (or IPv4 extension headers) is not enabled.
- A few other minor fixes and cleanup.
- Answered David Ahern's question about why use generic netlink instead
  of rtnetlink.

Tested:

Set Hop-by-Hop options on TCP/UDP socket and verified to be functional.

Tom Herbert (6):
  exthdrs: Create exthdrs_options.c
  exthdrs: Move generic EH functions to exthdrs_common.c
  exthdrs: Registration of TLV handlers and parameters
  exthdrs: Add TX parameters
  ip6tlvs: Add netlink interface
  ip6tlvs: Validation of TX Destination and Hop-by-Hop options

 include/net/ipv6.h         |  130 ++++++
 include/uapi/linux/in6.h   |   49 ++
 net/ipv6/Kconfig           |    4 +
 net/ipv6/Makefile          |    3 +-
 net/ipv6/datagram.c        |   51 +-
 net/ipv6/exthdrs.c         |  394 ++--------------
 net/ipv6/exthdrs_common.c  | 1097 ++++++++++++++++++++++++++++++++++++++++++++
 net/ipv6/exthdrs_options.c |  345 ++++++++++++++
 net/ipv6/ipv6_sockglue.c   |   39 +-
 9 files changed, 1710 insertions(+), 402 deletions(-)
 create mode 100644 net/ipv6/exthdrs_common.c
 create mode 100644 net/ipv6/exthdrs_options.c

-- 
2.7.4

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ