Message-ID: <CALx6S377W7g=hE1SO1Q72FNhKc7VyqA9+d5ExW2xh1iKhXtNvw@mail.gmail.com>
Date:   Sun, 2 Jun 2019 08:48:11 -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 Sun, Jun 2, 2019 at 2:54 AM Ahmed Abdelsalam <ahabdels.dev@...il.com> wrote:
>
> On Fri, 31 May 2019 10:34:03 -0700
> Tom Herbert <tom@...bertland.com> wrote:
>
> > 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
>
> Tom,
> Yes, the needs for users should prevail. But it’s not Tom or Ahmed alone who should define users needs.
> The comparison between "draft-herbert-ipv6-srh-ah-00" and "draft-ietf-6man-segment-routing-header" is
> missing some facts. The first patch of the SRH implementation was submitted to the kernel two years after
> releasing the SRH draft. By this time, the draft was a working group adopted and co-authored by several
> vendors, operators and academia. Please refer to the first SRH patch submitted to the kernel
> (https://patchwork.ozlabs.org/patch/663176/). I still don’t see the point of rushing to upstream something
> that has been defined couple of days ago. Plus there is nothing that prevents anyone to "innovate" in his
> own private kernel tree.

Ahmed,

While you seem to think that was just defined and came out the blue a
few days ago, in fact this has been in discussion for many months. The
simultaneous use of segment routing and authentication header was not
defined-- but it is defined for other routing types and extension
headers. The primary drivers of segment routing (the academics,
operators, and vendors you refer to) were reluctant to do this. For
the most part, these are mostly routing vendors who don't care about
preserving end-to-end host functionality like AH. In order to define
an interoperable protocol, the mutability of fields needs to be
defined. They were unwilling to commit to defining what is mutable in
their protocol, and it took an intervening action of the working group
chairs to force them to clarify the requirements so now we have
something.

IMO, this is straightforward bug fix. If you want to say that we need
to wait for IETF to take action, okay, but then I strongly suggest
that you actively participate in the process (i.e. send to 6man list
what you think about the draft), as opposed to just passively
deferring to it and assuming others will do the right thing.

Tom

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

Powered by blists - more mailing lists