netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Grothoff <grothoff@in.tum.de>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	knock@gnunet.org, jacob@appelbaum.net
Subject: Re: [PATCH] TCP: add option for silent port knocking with integrity protection
Date: Wed, 11 Dec 2013 21:39:42 +0100	[thread overview]
Message-ID: <52A8CD8E.8020201@in.tum.de> (raw)
In-Reply-To: <20131211122637.75b09074@nehalam.linuxnetplumber.net>

On 12/11/2013 09:26 PM, Stephen Hemminger wrote:
> On Wed, 11 Dec 2013 21:19:00 +0100
> Christian Grothoff <grothoff@in.tum.de> wrote:
> 
>> On 12/11/2013 09:01 PM, David Miller wrote:
>>> From: Christian Grothoff <grothoff@in.tum.de>
>>> Date: Tue, 10 Dec 2013 19:35:36 +0100
>>>
>>>> Only NAT implementations that change the SQN are not supported
>>>> (those should be rare, but we have no hard data on this).
>>>
>>> Even Linux's netfilter can and does do this, it is absolutely necessary
>>> for tracking SIP and FTP protocols, and it's also used in our virtual
>>> server load balancing modules.
>>>
>>
>> We're aware that Linux _can_ do this.  I was not aware it was doing this
>> for
>> SIP and FTP specifically; regardless, what implementations can do is less
>> important than what they are configured to do most of the time, and that's
>> what we'd need hard data on.  Anyway, I'd be very interested to learn how
>> you use this for SIP/FTP to evaluate the impact.  Do you have documentation
>> on this?
>>
>> As for server load balancing, I suspect that those are not the kinds of
>> services that one would typically use port knocking for.  Still, again a
>> good hint as to where trouble might lurk (and we will definitively include
>> those points in the next revision of the documentation).
> 
> The point is that doing it outside of TCP core is safer, less error prone
> and more flexible.
> 

I'm not sure how you drew that conclusion from what I or David said.
Outside of TCP core doesn't fix the NAT issues at all, having a
dozen user-space implementations with configuration quirks doesn't
really sound less error prone to me, and finally I do not even see
a reasonably sane way of doing the TCP payload authentication in
userspace (even writing a process that relays data won't work, as
then you'd loose the source address for the server process).  So
I'd go as far as saying that some of what we do cannot really be
done in userspace.  Now, maybe you mean something other than
"userspace" with "outside of TCP core", in which case I again totally
fail to relate this to what was said here before.

  reply	other threads:[~2013-12-11 20:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-10 18:35 [PATCH] TCP: add option for silent port knocking with integrity protection Christian Grothoff
2013-12-11 20:01 ` David Miller
2013-12-11 20:19   ` Christian Grothoff
2013-12-11 20:26     ` Stephen Hemminger
2013-12-11 20:39       ` Christian Grothoff [this message]
2013-12-11 21:25       ` Andi Kleen
2013-12-11 22:53         ` Christian Grothoff
2013-12-12  1:23           ` Andi Kleen
2013-12-12 10:19             ` Jacob Appelbaum
2013-12-12 11:43               ` Christian Grothoff
2013-12-12 12:23                 ` Jacob Appelbaum
2013-12-12 14:34                 ` Eric Dumazet
2013-12-12 15:07                   ` Christian Grothoff
2013-12-12 15:33                     ` Eric Dumazet
2013-12-12 15:46                   ` Hannes Frederic Sowa
2013-12-13  3:07                     ` Hannes Frederic Sowa
2014-08-19 19:36                   ` Alexander Holler
2014-08-20  8:24                     ` Hagen Paul Pfeifer
2014-08-20  9:07                       ` Alexander Holler
2014-08-20  9:28                         ` Hagen Paul Pfeifer
2014-08-20  9:47                           ` Alexander Holler
2014-08-20 10:20                             ` Alexander Holler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52A8CD8E.8020201@in.tum.de \
    --to=grothoff@in.tum.de \
    --cc=davem@davemloft.net \
    --cc=jacob@appelbaum.net \
    --cc=knock@gnunet.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).