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

[Chris Morrow]

At Thu, 27 Dec 2018 11:43:58 +0100,
Bjørn Mork <bjorn at mork.no> wrote:
> 
> 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 ;-)

'i am also not a freebsd person' but:
  https://wiki.freebsd.org/BjoernZeeb
bjorn had said when last I ran into him that he was still planning on working on AO :(
(he happens to also reply to the above thread, no details in reply)

> 
> > -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

I figured that: me: "There's no support in the device/code, I still have md5... md5 does what I want."
coupled with: vendor(s): "there's no support in base-os for our gear, no one is really asking for it..."

> 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?
> 

i also don't know and checking my sept conversation he didn't reply,
so I poked that just now.

> 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...
> 

ok, 2021 is better than 'never' or '2yrs after the next conversation'
right? :)

> Yes, another alternative is obviously running TCP in userspace. But I
> will gladly go to certificate hell if I can avoid that.

user-space tcp seems a bit more implementation specific and probably
means similar timeframes to solve... given the spread of OS/Vendor
problems.

-chris