Faster application handshakes with SYN/ACK payloads

[Adam Langley-2]

I posted this a while back and it gathered a little discussion:

http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt
(implementation in [1])

I would like to have this published as Experimental and to get an
option number assigned.

The spec itself includes a somewhat rambling justification because I
wanted to decouple the spec, which is more general, from the exact
reason that I wish to start testing this over the Internet at large.
However, in order to provoke discussion I think I should explain my
motivation:

This spec allows for opportunistic encryption of TCP connections with
no additional round trips. Details of the project can be found at [2],
however a quick summary follows:

Although SYN/ACK payloads could be used to accelerate many protocols,
I'm proposing that, for HTTP, the SYN/ACK payload contains an 8-byte
random nonce and a 32-byte eliptic-curve public value. The client can
then perform key agreement and send it's own public value, nonce and
any encrypted payload in the final ACK. (Or in a following packet,
that works fine too). Data is then encrypted using Salsa20/8 where the
key is SHA256(diffie-hellman output + server nonce + client nonce) and
the IVs are 0 and 2**63 for client->server and server->client, resp.

Obviously, this open to both a downgrade and man-in-the-middle attack.
For a specific user, it offers little real security. However,
amortised over a large set of users, any ISPs performing these attacks
on a large scale will be detected. (I plan on building a network of
hosts probing for large scale attacks.) Thus, eavesdroppers are
removed from the equation and, against the rest, it can protect most
of the people, most of the time.

I also plan to sign the resulting packets with TCP-AO at some point,
if possible. However, given that that is still under development I'm
going to make that part of the negotiation, above, so that it can be
deployed without it for now.

Obviously, this system can only prove itself in time. However, it
can't prove itself with an option number assigned. And thus, I'm
looking for a consensus that this is an interesting experiment.

Thanks

Having spoken to quite a few people about this, I now have an FAQ on
the design which is included below:

* Why Elliptic-curves?

The payload must be short otherwise SYN-floods could use this as an
amplification
to backscatter DDoS another host.

Also, the reduced computation cost (as compared to Diffie-Hellman over a
multiplicative finite field) is very nice.

* Why 25519?

It's very fast (2000 ops/sec with my C code. 4000 ops/sec with asm). Also, the
server's public value must be constant, otherwise an attacker could eat CPU
time with a SYN flood and curve25519 is designed for that.

Since this is constant for all connections, there is no perfect forward
secrecy.

* Can't you fit the client's public value in the SYN?

A SYN generally has 20 bytes of free option space these days. (We can't use the
payload space in a SYN). Since this can't be the last option ever, we need to
leave 4 bytes spare. 2 bytes for the option header means 14 bytes for the
public value. The closest prime is 2**112-75.

I'm a bear of little brain and picking my own curve is already a hell of a
task, but assuming that I can:

The best, general algorithm currently known for breaking the DH problem on
elliptic curves is Pollard's Rho. The work involved in this attack is sqrt(n),
which is 2**56 in this case. Critically, once you have solved a single instance
you can precompute tables to speed up breaking more instances. With a petabyte
of storage, you could break 112-bit curves in 2**12 operations, which is very
fast.

* Can't you use a smaller field anyway?

Some speedup could be gained by using an EC with a field size around 200 bits.
However the effort of defining such a curve is pretty huge. The standard NIST
curves around that size are slower:

http://www.cacr.math.uwaterloo.ca/techreports/2003/corr2003-18.pdf (table 6)

* Why Salsa20/8?

It encrypts at two cycles per byte on modern CPUs[1]. The best attack on this,
reduced round, variant is 2**251. It's very unlikely that an attack would ever
break it to the point that it's easier than performing a downgrade attack.

http://cr.yp.to/streamciphers/phase3speed-20080331.pdf



[1] http://code.google.com/p/obstcp/source/browse/trunk/patches/synack-payload
[2] http://code.google.com/p/obstcp/

--
Adam Langley agl@... http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Murali Bashyam]

There are firewalls that drop SYN packets carrying payload, since it's considered anomalous behaviour (rightly so given today's end-user
behaviour). Doesn't that defeat the purpose here? I suppose TCP options have been explored and ruled out for some reason?

On Thu, Jul 31, 2008 at 12:52 PM, Adam Langley <agl@...> wrote:

I posted this a while back and it gathered a little discussion:

http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt
(implementation in [1])

I would like to have this published as Experimental and to get an
option number assigned.

The spec itself includes a somewhat rambling justification because I
wanted to decouple the spec, which is more general, from the exact
reason that I wish to start testing this over the Internet at large.
However, in order to provoke discussion I think I should explain my
motivation:

This spec allows for opportunistic encryption of TCP connections with
no additional round trips. Details of the project can be found at [2],
however a quick summary follows:

Although SYN/ACK payloads could be used to accelerate many protocols,
I'm proposing that, for HTTP, the SYN/ACK payload contains an 8-byte
random nonce and a 32-byte eliptic-curve public value. The client can
then perform key agreement and send it's own public value, nonce and
any encrypted payload in the final ACK. (Or in a following packet,
that works fine too). Data is then encrypted using Salsa20/8 where the
key is SHA256(diffie-hellman output + server nonce + client nonce) and
the IVs are 0 and 2**63 for client->server and server->client, resp.

Obviously, this open to both a downgrade and man-in-the-middle attack.
For a specific user, it offers little real security. However,
amortised over a large set of users, any ISPs performing these attacks
on a large scale will be detected. (I plan on building a network of
hosts probing for large scale attacks.) Thus, eavesdroppers are
removed from the equation and, against the rest, it can protect most
of the people, most of the time.

I also plan to sign the resulting packets with TCP-AO at some point,
if possible. However, given that that is still under development I'm
going to make that part of the negotiation, above, so that it can be
deployed without it for now.

Obviously, this system can only prove itself in time. However, it
can't prove itself with an option number assigned. And thus, I'm
looking for a consensus that this is an interesting experiment.

Thanks

Having spoken to quite a few people about this, I now have an FAQ on
the design which is included below:

* Why Elliptic-curves?

The payload must be short otherwise SYN-floods could use this as an
amplification
to backscatter DDoS another host.

Also, the reduced computation cost (as compared to Diffie-Hellman over a
multiplicative finite field) is very nice.

* Why 25519?

It's very fast (2000 ops/sec with my C code. 4000 ops/sec with asm). Also, the
server's public value must be constant, otherwise an attacker could eat CPU
time with a SYN flood and curve25519 is designed for that.

Since this is constant for all connections, there is no perfect forward
secrecy.

* Can't you fit the client's public value in the SYN?

A SYN generally has 20 bytes of free option space these days. (We can't use the
payload space in a SYN). Since this can't be the last option ever, we need to
leave 4 bytes spare. 2 bytes for the option header means 14 bytes for the
public value. The closest prime is 2**112-75.

I'm a bear of little brain and picking my own curve is already a hell of a
task, but assuming that I can:

The best, general algorithm currently known for breaking the DH problem on
elliptic curves is Pollard's Rho. The work involved in this attack is sqrt(n),
which is 2**56 in this case. Critically, once you have solved a single instance
you can precompute tables to speed up breaking more instances. With a petabyte
of storage, you could break 112-bit curves in 2**12 operations, which is very
fast.

* Can't you use a smaller field anyway?

Some speedup could be gained by using an EC with a field size around 200 bits.
However the effort of defining such a curve is pretty huge. The standard NIST
curves around that size are slower:

http://www.cacr.math.uwaterloo.ca/techreports/2003/corr2003-18.pdf (table 6)

* Why Salsa20/8?

It encrypts at two cycles per byte on modern CPUs[1]. The best attack on this,
reduced round, variant is 2**251. It's very unlikely that an attack would ever
break it to the point that it's easier than performing a downgrade attack.

http://cr.yp.to/streamciphers/phase3speed-20080331.pdf



[1] http://code.google.com/p/obstcp/source/browse/trunk/patches/synack-payload
[2] http://code.google.com/p/obstcp/

--
Adam Langley agl@... http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

--
Rgds,
Murali Bashyam
(c) (510)6736915

----------------------------- CONFIDENTIAL --------------------
*****************************************************
This telecommunication and any data attached to, or included in it
is considered confidential, and is intended only for use by the named
recipient. The contents may be legally protected as any one or more of:
copyrighted material, trade-secret protected material, attorney-client
privileged material, attorney workproduct, or as material covered by
any other legally available means. If you received this material in
error, please notify the sender and destroy the original and all copies,
whether electronic or otherwise. Thank you.
*****************************************************
------------------------------ CONFIDENTIAL --------------------

_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Adam Langley-2]

On Thu, Jul 31, 2008 at 2:07 PM, Murali Bashyam <mbcoder@...> wrote:
> There are firewalls that drop SYN packets carrying payload, since it's
> considered anomalous behaviour (rightly so given today's end-user
> behaviour). Doesn't that defeat the purpose here? I suppose TCP options have
> been explored and ruled out for some reason?

See the section "Can't you fit the client's public value in the SYN?"
for a discussion about using options space for this.

Middleware is a quotidian worry for these sorts of proposals. I'm not
proposing that a payload be carried in the SYN packet, but rather the
SYN/ACK packet. However, you may have meant all packets with a SYN
flag set.

The spec talks about how to back off in the face of such middleware,
and I believe that's the best that can be done. Since this is an
opportunistic protocol, detection and downgrade at the client is fine.
My current implementation doesn't do it yet, but will if there's any
call for it.


Cheers,

AGL

--
Adam Langley agl@... http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Murali Bashyam wrote:
| There are firewalls that drop SYN packets carrying payload, since it's
| considered anomalous behaviour (rightly so given today's end-user
| behaviour).

Just because a system doesn't expect a packet doesn't mean it's an attack.

Data in SYNs is defined in 793; it can be ignored (i.e., ACK the SYN but
not the data), e.g., to reduce the server state until TWHS completes (or
uses cookies, as well), but dropping those packets is the anomalous
behavior here.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiSOfYACgkQE5f5cImnZrua3QCggjSiiCngIXXFbetwEjo++jAu
66IAnA0VUQVKV/nCr3HQ0c65WtwknETg
=ku1K
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Adam,

Adam Langley wrote:
| I posted this a while back and it gathered a little discussion:
|
| http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt
| (implementation in [1])

A few observations:

- - TCP is already permitted to send data in the SYN-ACK
        prohibiting it when the SA-PP option is missing violates
        RFC1122 sec 4.2.2.5 -- unknown options are silently ignored

        options that change TCP need to be explicitly acknowledged,
        and current (legacy) behavior should be assumed if not
        acknowledged

- - TCP is already 'backward compatible' with sources that ignore SA
payload data; that data is just retransmitted
        you note that SA-PP alters the app level protocol;
        it appears to alter its timing, but AFAICT the
        effect would be otherwise invisible to an app

- - The rule "For a given SYN, if any resulting SYNACK frame has a payload
then all resulting frames MUST have a payload" appears to disable
persists and ACKs as would be needed for proper operation when data is
not available in one or more direction

- - AFAICT, it isn't sensible to retransmit a SYN with the same ISN, port,
etc. and different options. Since you do not explicitly acknowledge the
option, how do you know which SYN is being ACKd - the presence of SA
data isn't sufficient (e.g., legacy TCPs could do this)

- - the diagrams need to include some corner cases:
        - when KX is larger than the PMTU in fig 3 (or NList is
        larger than the PMTU in fig 2)
        (i.e., it seems like there is a missing MUST NOT on the length)
        - how do you handle simultaneous opens?

- - can you explain why you use a bit-field for the TCP option flag,
rather than just using a 2-byte option? (i.e., KIND, length)

- ---




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiSRJYACgkQE5f5cImnZrvKHwCg9Ux1IGojUwuIQftRGmE3u6rz
blYAnRTLVK20rSDsKli+8Bil47/sOgHd
=ABOy
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Joe Touch wrote:
|
|
| Murali Bashyam wrote:
| | There are firewalls that drop SYN packets carrying payload, since it's
| | considered anomalous behaviour (rightly so given today's end-user
| | behaviour).
|
| Just because a system doesn't expect a packet doesn't mean it's an attack.
|
| Data in SYNs is defined in 793;...

PS - a SYN-ACK is just a SYN with the ACK set. It can have data just
like any other SYN. The only issue is that the data is not transmitted
to the app until the end of the TWHS; for the SYN-ACK, this is immediate
(vs. putting the data in the SYN).

T/TCP allows pushing the SYN data up to the app before the end of the
TWHS, which is different, as you note.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiSRPYACgkQE5f5cImnZrvf5ACghKyhW4xK3DLjn1cvFVzxGH2h
omUAnihed2wok3PiFU6EiJrT7YkBpJsu
=/vl7
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Adam Langley-2]

On Thu, Jul 31, 2008 at 4:02 PM, Joe Touch <touch@...> wrote:
> - - TCP is already permitted to send data in the SYN-ACK
>        prohibiting it when the SA-PP option is missing violates
>        RFC1122 sec 4.2.2.5 -- unknown options are silently ignored
>
>        options that change TCP need to be explicitly acknowledged,
>        and current (legacy) behavior should be assumed if not
>        acknowledged

Ah, I didn't know this. Thank you!

I don't believe changing TCP to disallow this is a good idea. However,
it's important that userland knows weather this experiment is in
effect. Thus, I believe that I should echo the SA-PP option in the
SYNACK. Also, it should probably change names: SYN/ACK Payloads
Processed or some similar.

> - - The rule "For a given SYN, if any resulting SYNACK frame has a payload
> then all resulting frames MUST have a payload" appears to disable
> persists and ACKs as would be needed for proper operation when data is
> not available in one or more direction

That's badly worded on my part. It should read:
"For a given SYN, if any resulting SYNACK frame has a payload then all
resulting SYNACK frames MUST have a payload"

(i.e. the restriction only apply to SYNACK frames. It's just so a host
cannot decide the retransmit a different SYNACK)

> - - AFAICT, it isn't sensible to retransmit a SYN with the same ISN, port,
> etc. and different options. Since you do not explicitly acknowledge the
> option, how do you know which SYN is being ACKd - the presence of SA
> data isn't sufficient (e.g., legacy TCPs could do this)

As you note, as another consequence of my misunderstanding, the
presence of SA data isn't sufficient to tell which SYN is getting
acked. Echoing the option should also solve this issue.

> - - the diagrams need to include some corner cases:
>        - when KX is larger than the PMTU in fig 3 (or NList is
>        larger than the PMTU in fig 2)
>        (i.e., it seems like there is a missing MUST NOT on the length)

It's suggested that the payload be limited to 64-bytes to prevent
amplification backscatter from a SYN flood. Thus these bytestrings
have to fit within the MTU. If an implementation doesn't enforce this,
then it has to drop support when replying on a link where the MTU is
insufficient.

>        - how do you handle simultaneous opens?

I believe that simultaneous opens work just fine, although both sides
will believe that the other doesn't support this experiment since the
option won't be echoed in the SYN.

> - - can you explain why you use a bit-field for the TCP option flag,
> rather than just using a 2-byte option? (i.e., KIND, length)

My hope was that by defining a flags option like this, future options
that require only to signal their presence in a SYN could save space.
If SACK permitted has been defined this way, for example, then this
draft wouldn't need to take any more space.

However, this is very subjective. If people would prefer not to do
this, or would prefer to break it out into its own draft, I'm
perfectly happy with that.


Thanks!

AGL

--
Adam Langley agl@... http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Adam Langley-2]

I've updated the draft with the following changes:
  * Fixed the wording around retransmissions which mistakenly
suggested that no packets of any type could be transmitted without
payloads
  * Renamed the flag to SYNACK Payloads Processed
  * Required that the flag be echoed in resulting SYNACK frames
  * Added discussion of simultaneous open
  * Added discussion of SYNACKs with payloads that are nothing to do
with this spec, noting that they are still permitted

I'll wait to see if there are more comments on -00 before publishing -01.

Cheers


AGL

--
Adam Langley agl@... http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Adam,

Adam Langley wrote:
| On Thu, Jul 31, 2008 at 4:02 PM, Joe Touch <touch@...> wrote:
|> - - TCP is already permitted to send data in the SYN-ACK
|>        prohibiting it when the SA-PP option is missing violates
|>        RFC1122 sec 4.2.2.5 -- unknown options are silently ignored
|>
|>        options that change TCP need to be explicitly acknowledged,
|>        and current (legacy) behavior should be assumed if not
|>        acknowledged
|
| Ah, I didn't know this. Thank you!
|
| I don't believe changing TCP to disallow this is a good idea. However,
| it's important that userland knows weather this experiment is in
| effect.

It's not an experiment; it's valid TCP behavior.

Why does the application need to know? As you note, it speeds up
application performance, but the app never knows how long the SYN
exchange takes anyway - or whether there are retransmissions.

- ------

Although there is more detailed feedback below, it might be useful to
raise this up a level.

If the purpose of this option is to encourage servers that know about
the option to potentially speed up their data transmission, then it
might be sufficient to just send the hint in the SYN. The SA would then
have the data if the server wanted to.

What if the server just assumed this? It seems like nothing
should break and it would work where it should anyway...

I.e., Nike's rule applies: "Just do it."
(no  need for an option)

(side note) Such an option might be useful, but might also be an issue.
It tests the fact that TCPs ignore unknown options, a test that might
fail. It also tests the fact that middleboxes should pass options
unmodified, which also might fail. Although either of these behaviors
would be out of spec, I wonder whether it's useful to try to optimize a
connection at the expense of it possibly failing.

If this option is intended to 'definitively speed up' connections,
there's nothing in TCP that is 'realtime'. Applications can't see things
like retransmission, or the fact that data in the SYN (and thus SYN-ACK)
need not be ACKd when the SYN (or SYNACK) is ACK'd. Application data
boundaries (writes) don't need to correspond to data segmentation
either. Overall, there seem like too many ways in which valid TCP
behavior can stall things for an extra RTT or so *anytime* during a
connection (including the handshake); forcing data into the SYNACK
doesn't seem productive if that's the case.

A change to TCP that makes this option visible seems like it's a change
to TCP semantics that requires broader modifications - the API needs to
be redefined, socket options (or the equivalent) need to be defined,
etc. For very short exchanges for which 1 RTT savings would be
significant, perhaps TCP isn't the right protocol to use, IMO. For
longer connections, the savings would be masked by other RTTs anyway.

- ------

The following are details, but it would be more useful to focus on the
above first...

- -- Joe


| Thus, I believe that I should echo the SA-PP option in the
| SYNACK.

You can, but it doesn't really matter. The SA-PP can be considered a
hint to the other end to encourage it to send data in the SA. If the SA
contains data, either the other end was suitably encouraged, or it
didn't need encouragement. Either way, the presence of the data in the
SA tells you what you need to know - that the other end sent data.

Either way, once your end receives SA data, it can allow its app layer
to access the data once the subsequent ACK is sent. As far as the
initiating end is concerned, the TWHS ends when that ACK is sent anyway.

| Also, it should probably change names: SYN/ACK Payloads
| Processed or some similar.
|
|> - - The rule "For a given SYN, if any resulting SYNACK frame has a
payload
|> then all resulting frames MUST have a payload" appears to disable
|> persists and ACKs as would be needed for proper operation when data is
|> not available in one or more direction
|
| That's badly worded on my part. It should read:
| "For a given SYN, if any resulting SYNACK frame has a payload then all
| resulting SYNACK frames MUST have a payload"

There is only one SYNACK segment in a connection in a given direction,
excepting retransmissions. There is no reason why retransmissions need
to include data - if the SA with data is received, either the SA is ACKd
or the SA and data are ACKd; if the SA without data is received, it
would be ACKd.

The result is that either the ACK says the SA data got there or not. If
not, then it would be retransmitted in a regular data packet.

Again, since TCP is NOT a 'realtime' protocol - and doesn't have a
'realtime' handshake', the application can't know or care about the
difference.

| (i.e. the restriction only apply to SYNACK frames. It's just so a host
| cannot decide the retransmit a different SYNACK)

See above; I don't see why it would, but I don't see why the application
could care.

...
|> - - the diagrams need to include some corner cases:
|>        - when KX is larger than the PMTU in fig 3 (or NList is
|>        larger than the PMTU in fig 2)
|>        (i.e., it seems like there is a missing MUST NOT on the length)
|
| It's suggested that the payload be limited to 64-bytes to prevent
| amplification backscatter from a SYN flood. Thus these bytestrings
| have to fit within the MTU. If an implementation doesn't enforce this,
| then it has to drop support when replying on a link where the MTU is
| insufficient.

A 576 MTU is the smallest size that endpoints agree to reassemble; it is
NOT the smallest MTU all links agree to support in the Internet. The
smallest MTU is 68 bytes - i.e., IP with all possible options, TCP with
none, and the smallest possible fragment (8 bytes) [see RFC791]. As a
result, a 64-byte payload is too large to assume that it won't be
fragmented (that may be true practically in many cases, but it isn't a
requirement).

|>        - how do you handle simultaneous opens?
|
| I believe that simultaneous opens work just fine, although both sides
| will believe that the other doesn't support this experiment since the
| option won't be echoed in the SYN.

A SA is just a SYN with an ACK. In simultaneous opens, the ACK for each
SYN comes alone. In that case, whether the ACK of the SYN (which, in
simultaneous open is just an ACK) could include the option and data if
it is sent after the other side's SYN is received. I.e., depending on
how the SYNs cross, the handshake might succeed or might not.

If confirming the option is critical, you need to handle this case. As
noted above, it might not be critical (or even necessary).

|> - - can you explain why you use a bit-field for the TCP option flag,
|> rather than just using a 2-byte option? (i.e., KIND, length)
|
| My hope was that by defining a flags option like this, future options
| that require only to signal their presence in a SYN could save space.

That might be a useful to document as a separate issue, since it's
orthogonal to this option. However, you'd need more rules, like the fact
that the responder needs to clear (or truncate) all bits it doesn't
understand or doesn't agree to.

It'd be useful to develop this more fully and get WG feedback on it
separately, IMO.

It's not always as efficient as it appears, FWIW: it trades efficiency
when many flags are set for inefficiency when only recent flags are
defined. E.g., the 25th such flag pays an extra 3-byte penalty when no
other flags are used.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiTUzcACgkQE5f5cImnZrvTAQCfSh/dutm/eQ0X5G7YjhgGB7rZ
WcgAn2utEgJoT/WLwrl8Kam7H3x37MRj
=o/TA
-----END PGP SIGNATURE-----

_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Matt Mathis]

Opps I posted to the wrong thread.   Sorry folks..

Doesn't this create a huge opportunity for a DoS attack, since an attacker can
send requests with forged from addresses, and the server has to
burn cycles and/or commit memory, when it is never going to see the next
packet?

I believe that this problem is fundamental to anything that is piggybacked on
the SYN and has killed every attempt at using the handshake to
eliminate later transactions.  The server wants to know for sure that the
client is alive and responding before committing more than incidental
resources (e.g. SYN queue, constructing a SYN-cookie, etc) to the connection.

Thanks,
--MM--
-------------------------------------------
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

On Thu, 31 Jul 2008, Adam Langley wrote:

> I posted this a while back and it gathered a little discussion:
>
> http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt
> (implementation in [1])
>
> I would like to have this published as Experimental and to get an
> option number assigned.
>
> The spec itself includes a somewhat rambling justification because I
> wanted to decouple the spec, which is more general, from the exact
> reason that I wish to start testing this over the Internet at large.
> However, in order to provoke discussion I think I should explain my
> motivation:
>
> This spec allows for opportunistic encryption of TCP connections with
> no additional round trips. Details of the project can be found at [2],
> however a quick summary follows:
>
> Although SYN/ACK payloads could be used to accelerate many protocols,
> I'm proposing that, for HTTP, the SYN/ACK payload contains an 8-byte
> random nonce and a 32-byte eliptic-curve public value. The client can
> then perform key agreement and send it's own public value, nonce and
> any encrypted payload in the final ACK. (Or in a following packet,
> that works fine too). Data is then encrypted using Salsa20/8 where the
> key is SHA256(diffie-hellman output + server nonce + client nonce) and
> the IVs are 0 and 2**63 for client->server and server->client, resp.
>
> Obviously, this open to both a downgrade and man-in-the-middle attack.
> For a specific user, it offers little real security. However,
> amortised over a large set of users, any ISPs performing these attacks
> on a large scale will be detected. (I plan on building a network of
> hosts probing for large scale attacks.) Thus, eavesdroppers are
> removed from the equation and, against the rest, it can protect most
> of the people, most of the time.
>
> I also plan to sign the resulting packets with TCP-AO at some point,
> if possible. However, given that that is still under development I'm
> going to make that part of the negotiation, above, so that it can be
> deployed without it for now.
>
> Obviously, this system can only prove itself in time. However, it
> can't prove itself with an option number assigned. And thus, I'm
> looking for a consensus that this is an interesting experiment.
>
> Thanks
>
> Having spoken to quite a few people about this, I now have an FAQ on
> the design which is included below:
>
> * Why Elliptic-curves?
>
> The payload must be short otherwise SYN-floods could use this as an
> amplification
> to backscatter DDoS another host.
>
> Also, the reduced computation cost (as compared to Diffie-Hellman over a
> multiplicative finite field) is very nice.
>
> * Why 25519?
>
> It's very fast (2000 ops/sec with my C code. 4000 ops/sec with asm). Also, the
> server's public value must be constant, otherwise an attacker could eat CPU
> time with a SYN flood and curve25519 is designed for that.
>
> Since this is constant for all connections, there is no perfect forward
> secrecy.
>
> * Can't you fit the client's public value in the SYN?
>
> A SYN generally has 20 bytes of free option space these days. (We can't use the
> payload space in a SYN). Since this can't be the last option ever, we need to
> leave 4 bytes spare. 2 bytes for the option header means 14 bytes for the
> public value. The closest prime is 2**112-75.
>
> I'm a bear of little brain and picking my own curve is already a hell of a
> task, but assuming that I can:
>
> The best, general algorithm currently known for breaking the DH problem on
> elliptic curves is Pollard's Rho. The work involved in this attack is sqrt(n),
> which is 2**56 in this case. Critically, once you have solved a single instance
> you can precompute tables to speed up breaking more instances. With a petabyte
> of storage, you could break 112-bit curves in 2**12 operations, which is very
> fast.
>
> * Can't you use a smaller field anyway?
>
> Some speedup could be gained by using an EC with a field size around 200 bits.
> However the effort of defining such a curve is pretty huge. The standard NIST
> curves around that size are slower:
>
> http://www.cacr.math.uwaterloo.ca/techreports/2003/corr2003-18.pdf (table 6)
>
> * Why Salsa20/8?
>
> It encrypts at two cycles per byte on modern CPUs[1]. The best attack on this,
> reduced round, variant is 2**251. It's very unlikely that an attack would ever
> break it to the point that it's easier than performing a downgrade attack.
>
> http://cr.yp.to/streamciphers/phase3speed-20080331.pdf
>
>
>
> [1] http://code.google.com/p/obstcp/source/browse/trunk/patches/synack-payload
> [2] http://code.google.com/p/obstcp/
>
> --
> Adam Langley agl@... http://www.imperialviolet.org
> _______________________________________________
> tcpm mailing list
> tcpm@...
> https://www.ietf.org/mailman/listinfo/tcpm
>

_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Adam Langley-2]

On Fri, Aug 1, 2008 at 12:04 PM, Matt Mathis <mathis@...> wrote:
> Doesn't this create a huge opportunity for a DoS attack, since an attacker
> can send requests with forged from addresses, and the server has to
> burn cycles and/or commit memory, when it is never going to see the next
> packet?

The additional requirements on the server when processing a SYN under
my scheme are:
  * At most, an additional 12 bytes of state in the request sock. At
least, another 5 bytes (depending on alignment etc)
  * Generating 8 random bytes
  * Transmitting an additional 45 bytes in the SYNACK frame (3 bytes
of option + 8 random bytes + 32 bytes of elliptic curve point + 2
bytes header)

The additional storage isn't that bad. Currently, in Linux a
tcp_request_sock is 96 bytes:
(gdb) print ((struct tcp_request_sock *) 0)[1]
Cannot access memory at address 0x60

So the additional space isn't that great. Random number generation
isn't too bad either. Also, the spec explicitly says that hosts can
decide not to support it under load (e.g. if they are switching to SYN
cookies).

I did consider defining a special echo option to save on the server's
storage, but decided that I didn't think it was worth the extra
complexity.

Of course, these are subjective judgements; one might reasonably
consider that to be too much work for a SYN.


Cheers

AGL

--
Adam Langley agl@... http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Adam Langley-2]

On Fri, Aug 1, 2008 at 11:17 AM, Joe Touch <touch@...> wrote:
> It's not an experiment; it's valid TCP behavior.

Whenever I'm speaking about an experiment, I mean this draft - it
being "experimental"

> Although there is more detailed feedback below, it might be useful to
> raise this up a level.

Thanks for your detailed response, I fear that there's a
misunderstanding somewhere and that's almost certainly the fault of my
inadequate writeups. Please let me try again:

At the moment, almost no stacks will send payloads in the SYNACK even
though they could as an optimisation. This springs from a few reasons:
  R1) Processing time for a SYN must be minimal to mitigate the
effects of SYN floods. Even waking up an application to process a SYN
would greatly increase the costs.
  R2) Replies to SYNs must be small, otherwise it provides a way to
amplify a DDoS attacks using false source IP addresses.
  R3) The ubiquitous sockets API doesn't make it easy to do so.

I'm proposing that a constant payload (optionally with 8 random bytes)
overcomes R1 and R3. And limiting the size of that payload to 64 bytes
overcomes R2.

There are protocols that could immediately benefit from a gradual
deployment of hosts which supported a setsockopt to set a constant
payload and hosts that would ACK and enqueue such a payload. (I
currently know of no stacks that do either however.) SMTP would be one
such protocol: clients wait for a 200 code banner from the server
before starting their part of the exchange and the banner is small and
constant. SMTP is also a protocol which ends up making many, short
connections.

Additionally, this would also be easy to deploy. For clients that
don't support it, they will ACK only the SYN flag and then the server
knows to include the payload again in the next frame.

However, the sockets API has guided the design of many application
level protocols. Because of this, these protocols are often designed
such that
  * The client starts the exchange: see HTTP
  * The exchange is large, since there's little space pressure: SSH
algorithm agreement uses strings like "diffie-hellman-group14-sha1"
(28 bytes) because of this.

Modifications to take advantage of SYNACK payloads would then require
changes to the application level protocol. This could be managed by
assigning new ports, trying connections on the new ports first,
backing off etc. However, given that this is a partly a latency
optimisation, that's an anathema.

So I additionally define an option that the application layer can set
and query that advertises support for this trick and allows many more
application level protocols to take advantage of it.

So, fundamentally, we end up with an opportunistic experiment that can
provide advantages, but may also have some costs if middleware gets
upset etc, as you note:

> (side note) Such an option might be useful, but might also be an issue.
> It tests the fact that TCPs ignore unknown options, a test that might
> fail. It also tests the fact that middleboxes should pass options
> unmodified, which also might fail.

Because of this, I wanted to make sure that clients were free to retry
a connection without the option in the case that something was
reacting badly to it. Many of the words in the draft are then
dedicated to making sure that both endpoints reach a consistent view
of when this option is in effect. Like the prohibition of not
including the option in a SYNACK if the previous SYNACK included it.
If that were to happen, the endpoint couldn't know which SYNACK the
peer saw and thus wouldn't know if the option was in effect or not.

For all of your comments that I have removed below, I hope that I've
addressed them in the above. If not, please highlight them again and I
will attempt to better do so.

Also, if the above was clearer then I should consider using it in the draft.

To address the remainder of your points:

> A 576 MTU is the smallest size that endpoints agree to reassemble; it is
> NOT the smallest MTU all links agree to support in the Internet. The
> smallest MTU is 68 bytes - i.e., IP with all possible options, TCP with
> none, and the smallest possible fragment (8 bytes) [see RFC791]. As a
> result, a 64-byte payload is too large to assume that it won't be
> fragmented (that may be true practically in many cases, but it isn't a
> requirement).

I don't believe that we should specify this. If a host finds itself in
a situation where the SYNACK payload is problematic in the face of the
MTU it may, validly, choose to fragment or to not echo the option. I
think the implementations have better information about which is the
best course of action.


> |>        - how do you handle simultaneous opens?
> If confirming the option is critical, you need to handle this case. As
> noted above, it might not be critical (or even necessary).

I believe that both sides will end up with a consistent view of
weather the option is in effect (neither will believe it to be so).

> | My hope was that by defining a flags option like this, future options
> | that require only to signal their presence in a SYN could save space.
> That might be a useful to document as a separate issue, since it's
> orthogonal to this option. However, you'd need more rules, like the fact
> that the responder needs to clear (or truncate) all bits it doesn't
> understand or doesn't agree to.

Yes, I'll add that words to that effect.

Looking at the list of currently assigned options, very few of them
are binary flags like this (SACK permitted is the other major one,
"Partial Order Connection Permitted", etc), suggesting that it might
not be worthwhile. As you point out:

> the 25th such flag pays an extra 3-byte penalty when no
> other flags are used.

Which is true. I'm happy with whatever the consensus is.



Cheers

AGL

--
Adam Langley agl@... http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Adam,

Again, popping up a level, you've made a good case for a socket option
that lets the server app signal its TCP to try to send data in the
SYNACK. TCPs that do this will; TCPs that don't will fail on the socket
option, and the server will know.

I am unclear why the client TCP is involved in this; if the data is
sent, it will either be acknowledged or retransmitted. There is no
change to the semantics, and only a change to timing (which NOTHING in
TCP ensures anyway).

As a minor note, it doesn't seem useful to extend that socket option to
say how much data to put in the SYNACK; nothing else in TCP knows about
application data boundaries, and I think it would be a mistake to assume
that. You might add something like:

        setsockopt(SEND_SA_DATA, bytecount)

where:
        bytecount = number of data bytes the app is *suggesting*
        the SA include; this is NOT guaranteed to be enforced
        by TCP

if the sockopt succeeds, the app should reasonably assume that bytecount
bytes are sent in the SYNACK if available when the SYNACK is sent

As a final question (I'm not a sockets expert), it might be that there
are other socket modifications to allow users to write to connections
that are not yet open (or can they just be queued up? in which case, it
seems like the socket must be completely bound, i.e., this might not
work for unbound LISTENs).

Specific notes below...

Joe

Adam Langley wrote:
...
| Thanks for your detailed response, I fear that there's a
| misunderstanding somewhere and that's almost certainly the fault of my
| inadequate writeups. Please let me try again:
|
| At the moment, almost no stacks will send payloads in the SYNACK even
| though they could as an optimisation. This springs from a few reasons:
|   R1) Processing time for a SYN must be minimal to mitigate the
| effects of SYN floods. Even waking up an application to process a SYN
| would greatly increase the costs.
|   R2) Replies to SYNs must be small, otherwise it provides a way to
| amplify a DDoS attacks using false source IP addresses.
|   R3) The ubiquitous sockets API doesn't make it easy to do so.

This s