2014-02-12 10:25:44

by Nawn Given

[permalink] [raw]
Subject: Experimental Privacy Functions and TCP SYN Payloads

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.


2014-02-12 11:35:44

by Daniel Borkmann

[permalink] [raw]
Subject: Re: Experimental Privacy Functions and TCP SYN Payloads

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

2014-02-12 15:51:58

by Yuchung Cheng

[permalink] [raw]
Subject: Re: Experimental Privacy Functions and TCP SYN Payloads

On Wed, Feb 12, 2014 at 3:35 AM, Daniel Borkmann <[email protected]> wrote:
> (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?
For 3.7+ you can use TCP Fast Open.

For a quick trial experiment, you can just set
sysctl net.ipv4.tcp_fastopen=0x603 on both end hosts and use
sendmsg(..., MSG_FASTOPEN) instead of connect() then send(). the
sendmsg() will behave as a combo call of connect() and send() and
return similar errno. accept() will return after data in the SYN is
received instead of after handshake is completed.

>>
>> -
>>
>> [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.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html