netdev - Re: [PATCH net-next 6/6] seg6: Add support to rearrange SRH for AH ICV calculation

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] [day] [month] [year] [list]

Message-ID: <CAPDqMeqvq-w8VRcw6gb1qnUntBno7G+hLD6U1ZECdNfMyAQm3Q@mail.gmail.com>
Date:   Fri, 31 May 2019 07:47:58 -0700
From:   Tom Herbert <tom@...ntonium.net>
To:     Ahmed Abdelsalam <ahabdels.dev@...il.com>
Cc:     Tom Herbert <tom@...bertland.com>,
        "David S . Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        dlebrun@...gle.com
Subject: Re: [PATCH net-next 6/6] seg6: Add support to rearrange SRH for AH
 ICV calculation

On Fri, May 31, 2019 at 7:05 AM Ahmed Abdelsalam <ahabdels.dev@...il.com> wrote:
>
> On Thu, 30 May 2019 14:50:21 -0700
> Tom Herbert <tom@...bertland.com> wrote:
>
> > Mutable fields related to segment routing are: destination address,
> > segments left, and modifiable TLVs (those whose high order bit is set).
> >
> > Add support to rearrange a segment routing (type 4) routing header to
> > handle these mutability requirements. This is described in
> > draft-herbert-ipv6-srh-ah-00.
> >
>
> Hi Tom, David,
> I think it is very early to have such implementation in the mainline of the Linux kernel.
> The draft (draft-herbert-ipv6-srh-ah-00) has been submitted to IETF draft couple of days ago.
> We should give the IETF community the time to review and reach a consensus on this draft.

Hi Ahmed,

That draft is based on the mutability requirements specified in
draft-ietf-6man-segment-routing-header-19. It was quite an arduous
battle even to get them to nail down any requirements about what bits
the network is allowed to change (and even though the that draft is in
WGLC, they _still_ are making changes in the area). IMO, the AH
requirements should be part of the SRH specification as it is with any
other extension headers, but the WG chairs decided to defer that to
other docs and that is their prerogative-- hence my draft in response
which is simple and straightforward.

Regardless of the history and current state though, the current
implementation allows both AH and SRH to be configured simultaneously.
This won't work. If a user does this they may be in a world of hurt
because the effects may be non deterministic. For instance, some
packets for a flow might take a route that uses SRH, and some may not,
so some packets get through and others don't-- that's going to be hard
to debug.

IMO, we shouldn't wait for IETF to get their act together on this
which in their time frame can be years. We should take action to
address an identified issue that could adversely impact users. If
implementing this method isn't the right direction, please suggest an
alternative.

Thanks,
Tom

> Thanks,
> Ahmed
>
> --
> Ahmed Abdelsalam <ahabdels.dev@...il.com>