netdev - Re: [PATCH v5 net-next 5/7] ip6tlvs: Add TX parameters

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALx6S36RXXQgDqGGxnR=DRJyrweh5ARhS2YH1xHj9PJZb0AUNQ@mail.gmail.com>
Date:   Sat, 14 Dec 2019 11:19:46 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     Simon Horman <simon.horman@...ronome.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Tom Herbert <tom@...ntonium.net>
Subject: Re: [PATCH v5 net-next 5/7] ip6tlvs: Add TX parameters

On Sun, Oct 6, 2019 at 6:25 AM Simon Horman <simon.horman@...ronome.com> wrote:
>
> On Thu, Oct 03, 2019 at 02:58:02PM -0700, Tom Herbert wrote:
> > From: Tom Herbert <tom@...ntonium.net>
> >
> > Define a number of transmit parameters for TLV Parameter table
> > definitions. These will be used for validating TLVs that are set
> > on a socket.
> >
> > Signed-off-by: Tom Herbert <tom@...bertland.com>
> > ---
> >  include/net/ipeh.h         | 18 ++++++++++++++++
> >  include/uapi/linux/ipeh.h  |  8 +++++++
> >  net/ipv6/exthdrs_common.c  | 53 +++++++++++++++++++++++++++++++++++++++++++++-
> >  net/ipv6/exthdrs_options.c | 45 +++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 123 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/net/ipeh.h b/include/net/ipeh.h
> > index aaa2910..de6d9d0 100644
> > --- a/include/net/ipeh.h
> > +++ b/include/net/ipeh.h
>
> ...
>
> > @@ -54,6 +65,13 @@ struct tlv_param_table {
> >
> >  extern struct tlv_param_table ipv6_tlv_param_table;
> >
> > +/* Preferred TLV ordering for HBH and Dest options (placed by increasing order)
> > + */
> > +#define IPEH_TLV_PREF_ORDER_HAO                      10
> > +#define IPEH_TLV_PREF_ORDER_ROUTERALERT              20
> > +#define IPEH_TLV_PREF_ORDER_JUMBO            30
> > +#define IPEH_TLV_PREF_ORDER_CALIPSO          40
> > +
>
> Hi Tom,
>
> Could you expand on why thse values were chosen?
>
Pseudo random selection :-). The idea of having an ordering is to
constrain the use of TLVs (in some environments there may be TLV
ordering requirements or optimizations around specific ordering). Note
that the ordering only applies to validation of TLVs being set to
send, there are no ordering constraints in RX. Also, in the next patch
set where application can set individual HBH and DO options on a
socket, the ordering attribute is used to always produce the same
order on the wire regardless of the ordering that the application set
the options. For non-priviledeged applications especially, I believe
it's good to be conservative and apply reasonable constraints such as
ordering for TX (i.e. follow robustness principle).

> I can see that this patch implements a specific use of
> the 255 indexes available. But its not at all clear to me that
> this use fits expected use-cases (because I don't know what they are).
>
There are at more 253 non-padding option types. Fortunately the
protocol designers had the foresight to limit option type to a byte
and so it's reasonable to represent for lookup in simple arrays. Two
bytes for type would have been much more painful (compare lookup on
EtherType to IP protocol numbers for instance).

> ...