netdev - Re: [RFC v2 PATCH 0/5] seg6: Segment routing fixes

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:   Sat, 8 Jun 2019 08:27:20 -0700
From:   Tom Herbert <tom@...ntonium.net>
To:     David Lebrun <dav.lebrun@...il.com>
Cc:     Tom Herbert <tom@...bertland.com>,
        "David S . Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        David Lebrun <dlebrun@...gle.com>
Subject: Re: [RFC v2 PATCH 0/5] seg6: Segment routing fixes

On Sat, Jun 8, 2019 at 3:39 AM David Lebrun <dav.lebrun@...il.com> wrote:
>
> On 07/06/2019 19:55, Tom Herbert wrote:
> > This patch set includes fixes to bring the segment routing
> > implementation into conformance with the latest version of the
> > draft (draft-ietf-6man-segment-routing-header-19). Also, segment
> > routing receive function calls ip6_parse to properly parse TLVs
> > in parsing loop.
>
> Thanks for your patch set !
>
> General comment regarding uapi changes: it might be wise to wait for RFC
> status in case the IESG or IANA decide different type/flags values.

David,

It's a "chicken and the egg problem". If we wait for publication to
implement the protocol, then we can't implement the protocol which is
necessary for publication. So we have to implement and deploy Internet
Drafts, but the definition of I-Ds expressly makes them "works in
progress" that can change at any time.

In this case, the segment routing draft is in working group last call
so it's unlikely that any major changes will occur. There is one
proposed change in changing a padding value, it has not been accepted
by the WG. IESG and IANA are very unlikely to impose different
protocol parameter values. A potential hangup for publication is that
there is very little evidence that large portions of the draft have
been implemented. Linux is the only draft cited as having implemented
TLVs and HMAC, but as these patches point out it's pretty out of date
(HMAC flag stil used, no padding, no parse loop). These patches should
help the argument that segment routing can move forward.

Tom