Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[tcpcrypt-dev] tcpcrypt userland tests 3 and 6 fail

Andrea Bittau bittau at
Wed Jul 23 10:16:51 PDT 2014

On Wed, Jul 23, 2014 at 10:06 AM, Daniel Kahn Gillmor
<dkg at> wrote:
> On 07/23/2014 01:20 AM, Andrea Bittau wrote:
>> great - if the code works properly, it basically means that the CRYPT
>> option was stripped by a middlebox on your SYN to our check server.
> OK, i think i can confirm that the "middlebox" in question was the kvm
> userspace networking translation layer (which makes sense, since it
> wouldn't be capable of setting TCP options as a non-privileged user on
> the forwarded traffic).
> I've successfully used the latest build of tcpcrypt now from the network
> here at IETF-90.
>> The good news is that tcpcrypt wouldn't cause your internet to die -
>> i.e., it gracefully fell back to vanilla TCP.
> yep, that's a sensible approach.
>> The implementation is now super aggressive and disables tcpcrypt if
>> all tests don't fully pass.  Maybe I should change the code to disable
>> tcprypt only if tcpcrypt fully fails: e.g., connections HANG rather
>> than being downgraded.  What do you think?
> i think that's reasonable for now.  we should talk about what you think
> the right packaging strategy should be.  I'm thinking the approach
> should be something like (these are sequential steps):
>  0) create one package, tcpcrypt with just tcpcryptd and tcnetstat and
> and test/tcpcrypt, without any sort of system
> initialization. To do this, it would be really nice to have some
> documentation, even if just simple manpages.  i can write up some pod if
> that would be useful and we can feed it through pod2man, or we could add
> --help and --version options to the executables directly and use help2man.

It'd be great if you can write some man pages.

The key components are tcpcryptd, and (so people can get the session ID and start using
tcpcrypt for authentication).  tcnetstat is really nice to have for
debugging.  test/tcpcrypt is not critical I think.  That was more for
getting the numbers for the paper.  A port of netcat that prints the
session ID would be cool.

>  1) create a tcpcrypt-dev package that has a symlink  and
> the header files (and maybe tcs) -- this package will help people who
> want to link their tools into libtcpcrypt.

Yeah we need this.

>  2) create a systemd .service file and/or a sysvinit script which sets
> up the iptables-based redirection.

Totally.  I wonder whether it should call or in
fact we should get rid of the script entirely and just use init
scripts.  After all, it's all OS-dependent so init scripts might be
best?  I suggest using the OS init scripts and launching tcpcryptd

One thing I want to keep though: if tcpcryptd crashes, the firewall
rules should be reset to avoid network blockage.  That's the night
thing of  So maybe we do need a script after all.
I'm not sure how to accomplish this with the init scripts.  If it's
not possible, then the init script should call

>  3) look into packaging the kernel modules (for debian, this is likely
> to be a dkms [0] source package).  I expect this to come later -- we can
> focus on the userspace tools first.

Yes we should focus on the userspace.  We actually had people (and
companies) contact us saying that they'd deploy the user space version
but not the kernel!  So there's a lot of interest in the userspace

The kernel version is outdated at this time.

> note that debian also has two ports that use the freebsd kernel -- i'm
> not sure what the right approach to packaging tcpcryptd on that
> platform, it may take a bit of gymnastics.

Cool.  The good news is that tcpcrypt works on freebsd!

> Any suggestions or concerns?

Please go ahead when able!

thanks for all the good work.

>         --dkg
> [0]

More information about the tcpcrypt-dev mailing list