[j-nsp] About Secure Transport for RPKI on JUNOS

[Bjørn Mork]

Chris Morrow <morrowc at ops-netman.net> writes:
> On Wed, 26 Dec 2018 14:11:19 -0500,
> sthaug at nethelp.no 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