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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAAedzxpG77vB3Z8XsTmCYPRB2Hn43otPMXZW4t0r3E-Wh98kNQ@mail.gmail.com>
Date:   Fri, 3 Jan 2020 15:53:37 -0800
From:   Erik Kline <ek@...n.com>
To:     Tom Herbert <tom@...bertland.com>
Cc:     David Miller <davem@...emloft.net>,
        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, 3 Jan 2020 at 15:49, Tom Herbert <tom@...bertland.com> wrote:
>
> 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

And the problems that can be introduced by changing the effective path MTU...

> 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

FWIW the SRv6 header insertion stuff is still under discussion in
spring wg (last I knew).  I proposed one option that could be used to
avoid insertion (allow for extra scratch space
https://mailarchive.ietf.org/arch/msg/spring/UhThRTNxbHWNiMGgRi3U0SqLaDA),
but nothing has been conclusively resolved last I checked.

As everyone probably knows, the draft-ietf-* documents are
working-group-adopted documents (though final publication is never
guaranteed).  My current reading of 6man tea leaves is that neither
"ICMP limits" and "MTU option" docs were terribly contentious.
Whether code reorg is important for implementing these I'm not
competent enough to say.