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: <CALx6S34m31vQQoy6-Esf9N3nYBUhQPMubPC3tXqT6RQbKzkhCQ@mail.gmail.com>
Date:   Fri, 31 May 2019 10:34:03 -0700
From:   Tom Herbert <tom@...bertland.com>
To:     Ahmed Abdelsalam <ahabdels.dev@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        dlebrun@...gle.com, Tom Herbert <tom@...ntonium.net>
Subject: Re: [RFC PATCH 6/6] seg6: Add support to rearrange SRH for AH ICV calculation

On Fri, May 31, 2019 at 10:07 AM Ahmed Abdelsalam
<ahabdels.dev@...il.com> wrote:
>
> On Fri, 31 May 2019 09:48:40 -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,
> Assuming that IETF process needs to be fixed, then, IMO, should not be on the cost of breaking the kernel process here.

Ahmed,

I do not see how this is any way breaking the kernel process. The
kernel is beholden to the needs of users provide a robust and secure
implementations, not to some baroque IETF or other SDO processes. When
those are in conflict, the needs of our users should prevail.

> Let us add to the kernel things that have been reviewed and reached some consensus.

By that argument, segment routing should never have been added to the
kernel since consensus has not be reached on it yet or at least
portions of it. In fact, if you look at this patch set, most of the
changes are actually bug fixes to bring the implementation into
conformance with a later version of the draft. For instance, there was
never consensus reached on the HMAC flag; now it's gone and we need to
remove it from the implementation.

> For new features that still need to be reviewed we can have them outside the kernel tree for community to use.
> This way the community does not get blocked by IETF process but also keep the kernel tree stable.

In any case, that does not address the issue of a user using both
segment routing and authentication which leads to adverse behaviors.
AFAICT, the kernel does not prevent this today. So I ask again: what
is your alternative to address this?

Thanks,
Tom

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ