Chris Morrow <[email protected]> writes: > On Wed, 26 Dec 2018 14:11:19 -0500, > [email protected] wrote: >> >> Now if Juniper could implement TCP-AO and then donate the implementation >> to FreeBSD? :-) > > This was sort of my point, yes. > Thanks, as always for your cogent point(s).
I don't follow FreeBSD development, but googling for TCP-AO implementations a couple of months ago led me to believe they already did? Ref https://lists.freebsd.org/pipermail/freebsd-transport/2016-March/000101.html I'm sure someone will set me straight now ;-) > -chris > (without something to break the ao logjam we'll just keep on having > this argument, maybe we can isntead paste-bin this thread and just > refer all other callers there? :) ) The fact that the work was mostly done 10 years ago, but no one has bothered to finish the job, shows us what we should expect of the next 10 years: https://marc.info/?l=linux-netdev&m=121642691623828 https://marc.info/?l=linux-netdev&m=121642691723832 https://marc.info/?l=linux-netdev&m=121642691823836 I don't know why Adam never pushed this patch set further. There weren't any major objections to it AFAICS. Maybe I'm missing something? Getting traction after losing it is hard. The problem now is that even if you took this code, rebased it to current net-next and did the necessary fixups, then it would go into Linux v4.22 (or 5.whatever) released in April 2019. The feature would then go into the next major distro releases *after* the releases which are already being prepared for 2019. This means TCP-AO might be available for applications running on plain Debian stable or RHEL kernels in 2021. And that's being a bit of an optimist... Yes, another alternative is obviously running TCP in userspace. But I will gladly go to certificate hell if I can avoid that. Bjørn _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
