All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <borkmann@iogearbox.net>
To: Quinn Wood <wood.quinn.s@gmail.com>
Cc: linux-kernel@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: Experimental Privacy Functions and TCP SYN Payloads
Date: Wed, 12 Feb 2014 12:35:35 +0100	[thread overview]
Message-ID: <52FB5C87.50408@iogearbox.net> (raw)
In-Reply-To: <CAM83q7AiCBc5qSH18KhBHYknYf67Pnjkd3JUbC_WrBwefxHJMg@mail.gmail.com>

(please cc netdev)

On 02/12/2014 11:25 AM, Quinn Wood wrote:
> If program on host A spoofs the source address of an outgoing IPv4 packet then
> places that address in the first 32 bits of a UDP payload, a program on host B
> that is aware of these behaviors can still reply to the program on host A. [1]
>
> Continuing with this approach the program on host A could encrypt the UDP pay-
> load in a way that the program on host B can decrypt, and effectively reduce
> the ability of others in the wide network to passively determine who host A is
> sending transmissions to while simultaneously ensuring the program on host B
> can respond to the program on host A. [2]
>
> I'm uncertain how to proceed if I want to use TCP for stateful connections.
> The requirement of a handshake before data is handed off to the program means
> this approach won't work out of the box. I'm looking for any insight folks may
> have regarding this.
>
> My original approach to the handshake included setting one of the reserved
> bits in the TCP header to indicate the first 32 bits of the payload were the
> real source address. However this would be reliant on SYN packets containing
> a payload. Does the Linux kernel allow this?
>
> -
>
> [1] Barring any non store-and-forward network behavior like dropping packets
>      with questionable source addresses. Considering recent NTP-related  news
>      this seems to be a not-entirely common activity :)
> [2] This is of course reliant on both programs knowing the proper key for the
>      other.

  reply	other threads:[~2014-02-12 11:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-12 10:25 Experimental Privacy Functions and TCP SYN Payloads Quinn Wood
2014-02-12 11:35 ` Daniel Borkmann [this message]
2014-02-12 15:51   ` Yuchung Cheng

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=52FB5C87.50408@iogearbox.net \
    --to=borkmann@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=wood.quinn.s@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.