netdev - Re: [PATCH v8 net-next 0/9] ipv6: Extension header infrastructure

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]

Date:   Fri, 3 Jan 2020 15:48:50 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     David Miller <davem@...emloft.net>
Cc:     Ahmed Abdelsalam <ahabdels.dev@...il.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Simon Horman <simon.horman@...ronome.com>,
        Willem de Bruijn <willemdebruijn.kernel@...il.com>
Subject: Re: [PATCH v8 net-next 0/9] ipv6: Extension header infrastructure

On Fri, Jan 3, 2020 at 2:57 PM David Miller <davem@...emloft.net> wrote:
>
> From: Tom Herbert <tom@...bertland.com>
> Date: Fri, 3 Jan 2020 14:31:58 -0800
>
> > On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@...emloft.net> wrote:
> >>
> >> From: Tom Herbert <tom@...bertland.com>
> >> Date: Fri, 3 Jan 2020 09:35:08 -0800
> >>
> >> > The real way to combat this provide open implementation that
> >> > demonstrates the correct use of the protocols and show that's more
> >> > extensible and secure than these "hacks".
> >>
> >> Keep dreaming, this won't stop Cisco from doing whatever it wants to do.
> >
> > See QUIC. See TLS. See TCP fast open. See transport layer encryption.
> > These are prime examples where we've steered the Internet from host
> > protocols and implementation to successfully obsolete or at least work
> > around protocol ossification that was perpetuated by router vendors.
> > Cisco is not the Internet!
>
> Seriously, I wish you luck stopping the SRv6 header insertion stuff.
>
Dave,

I agree we can't stop it, but maybe we can steer it to be at least
palatable. There are valid use cases for extension header insertion.
Ironically, SRv6 header insertion isn't one of them; the proponents
have failed to offer even a single reason why the alternative of IPv6
encapsulation isn't sufficient (believe me, we've asked _many_ times
for some justification and only get hand waving!). There are, however,
some interesting uses cases like in IOAM where the operator would like
to annotate packets as they traverse the network. Encapsulation is
insufficient if they don't know what the end point would be or they
don't want the annotation to change the path the packets take (versus
those that aren't annotated).

The salient problem with extension header insertion is lost of
attribution. It is fundamental in the IP protocol that the contents of
a packet are attributed to the source host identified by the source
address. If some intermediate node inserts an extension header that
subsequently breaks the packet downstream then there is no obvious way
to debug this. If an ICMP message is sent because of the receiving
data, then receiving host can't do much with it; it's not the source
of the data in error and nothing in the packet tells who the culprit
is. The Cisco guys have at least conceded one point on SRv6 insertion
due to pushback on this, their latest draft only does SRv6 insertion
on packets that have already been encapsulated in IPIP on ingress into
the domain. This is intended to at least restrict the modified packets
to a controlled domain (I'm note sure if any implementations enforce
this though). My proposal is to require an "attribution" HBH option
that would clearly identify inserted data put in a packet by
middleboxes (draft-herbert-6man-eh-attrib-00). This is a tradeoff to
allow extension header insertion, but require protocol to give
attribution and make it at least somewhat robust and manageable.

Tom