Experimental Privacy Functions and TCP SYN Payloads

Experimental Privacy Functions and TCP SYN Payloads

[Quinn Wood]

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.

Re: Experimental Privacy Functions and TCP SYN Payloads

[Daniel Borkmann]

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

Re: Experimental Privacy Functions and TCP SYN Payloads

[Yuchung Cheng]

On Wed, Feb 12, 2014 at 3:35 AM, Daniel Borkmann <borkmann@iogearbox.net> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html