Faster application handshakes with SYN/ACK payloads

[Adam Langley-2]

Although I cannot attend Dublin, I though that I would post this
before the meeting in case people wished to discuss it there.

For the record, I'm still advocating that long options be an
experimental RFC although my work has switched to using the tricks
detailed in this draft.

Thanks go to Wes Eddy for comments on the previous version of this draft.

http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt

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

[Lloyd Wood]

This looks awfully like reinventing transactional TCP to me - and IIRC  
the reason that never got widely adopted was the increased potential  
for DOS attacks by tying up memory early on with a loaded SYN.

What am I missing?


On 15 Jul 2008, at 19:11, Adam Langley wrote:

> Although I cannot attend Dublin, I though that I would post this
> before the meeting in case people wished to discuss it there.
>
> For the record, I'm still advocating that long options be an
> experimental RFC although my work has switched to using the tricks
> detailed in this draft.
>
> Thanks go to Wes Eddy for comments on the previous version of this  
> draft.
>
> http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt
>
> --
> Adam Langley agl@... http://www.imperialviolet.org
> _______________________________________________
> tcpm mailing list
> tcpm@...
> https://www.ietf.org/mailman/listinfo/tcpm

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><L.Wood@...>





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

[Adam Langley-2]

On Tue, Jul 15, 2008 at 11:22 AM, Lloyd Wood <L.Wood@...> wrote:
> This looks awfully like reinventing transactional TCP to me - and IIRC the
> reason that never got widely adopted was the increased potential for DOS
> attacks by tying up memory early on with a loaded SYN.
>
> What am I missing?

There's a short section in the draft comparing it to T/TCP, but the
quick version:
  * For a given SYN there's one bit of additional state required (and
the draft says that a host can completely ignore a SYNACK Payload
Permitted bit if it's under heavy load and using cookies etc)
  * There's no payload in the SYN, so you can't send data to an
application from an unverified source address

In short, I don't believe that any of the T/TCP objections apply to
this draft, although I could be wrong. I suggest that the similarities
with it are only superficial.

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 (et al.),

I looked this over, and had a clarification:

Data could *always* come in the SYN/ACK (i.e., in a SYN), but often it's
just ignored. So this option is just a hint to the server that the
client won't ignore that data. It doesn't change any rules about data
delivery; once the SYN/ACK arrives, the client can send that data up to
the user as per conventional rules, AFAICT.

Adam Langley wrote:
| On Tue, Jul 15, 2008 at 11:22 AM, Lloyd Wood <L.Wood@...> wrote:
|> This looks awfully like reinventing transactional TCP to me - and
IIRC the
|> reason that never got widely adopted was the increased potential for DOS
|> attacks by tying up memory early on with a loaded SYN.

Transaction TCP allows a server to push data to the user that arrives in
the SYN without waiting for the client's final ACK; that doesn't appear
to be related to this.

I think the only catch is that this works only when there's a
unidirectional-initiated connection from client to server, and only
helps hint the server that the client will accept data in the SYN/ACK.
It doesn't help with simultaneous opens, e.g., since neither side can
send the data up until their SYN is ACK'd -- *that* is what T/TCP
changes, but this doesn't, again AFAICT.

I'm really not sure what buying a single RTT will do for TCP, though.
Very few exchanges that need reliable transfer of a single packet need
TCP, IMO.

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

iD8DBQFIfQ4NE5f5cImnZrsRAhXdAKC54DBHXzDHYMLhyoIebf1WuF5puACfcEnj
rl+lp9HBV6XIGjhfaBnu7YA=
=MHdC
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

[Adam Langley-2]

On Tue, Jul 15, 2008 at 1:52 PM, Joe Touch <touch@...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Data could *always* come in the SYN/ACK (i.e., in a SYN), but often it's
> just ignored. So this option is just a hint to the server that the
> client won't ignore that data. It doesn't change any rules about data
> delivery; once the SYN/ACK arrives, the client can send that data up to
> the user as per conventional rules, AFAICT.

Although I've not tested it, I suspect that you're correct here. I
should reword that section of the draft.

> I'm really not sure what buying a single RTT will do for TCP, though.
> Very few exchanges that need reliable transfer of a single packet need
> TCP, IMO.

Although it could be used for single packet exchanges from the server,
I would be surprised if any one did. My expectation is that protocols
would use it to shave a RTT from the TCP connection setup latency. My
personal motivation for this draft is hinted at in section 2:

"This also allows existing protocols to be extended with encryption
with no additional round trips and with transparent fallback."

Consider a web browser which sets the SYNACK permitted bit and a web
server which includes an elliptic-curve Diffie Hellman key in it's
static SYNACK payload. When connecting to a normal webserver, the
browser will see that no SYNACK payload was received and carry on as
normal. But for augmented webservers, the browser calculate a shared
key and include its own ECDH key just before the HTTP "GET" request,
carried in the final ACK of the 3-way. Thus we have opportunistic
encryption and no additional latency in either case.

(Also, that's not just idle speculation: the firefox build that I'm
writing this email in is such a web browser and the lighttpd I have
running at home is such a web server.)

Cheers

AGL

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

[Adam Langley-2]

On Tue, Jul 15, 2008 at 11:29 AM, Adam Langley <agl@...> wrote:
>  * For a given SYN there's one bit of additional state required (and
> the draft says that a host can completely ignore a SYNACK Payload
> Permitted bit if it's under heavy load and using cookies etc)

I screwed that up, sorry. If you're asking the kernel to generate an
nonce for you, it has to remember the value, so that's actually 9
bytes of state.


AGL

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

[Michael Scharf-4]

Hi Adam,

On Tue, 15 Jul 2008 at 14:15:13, Adam Langley wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Data could *always* come in the SYN/ACK (i.e., in a SYN), but often it's
> > just ignored. So this option is just a hint to the server that the
> > client won't ignore that data. It doesn't change any rules about data
> > delivery; once the SYN/ACK arrives, the client can send that data up to
> > the user as per conventional rules, AFAICT.
>
> Although I've not tested it, I suspect that you're correct here. I
> should reword that section of the draft.

sorry for asking once again "stupid" questions: Wouldn't it be a
simple solution if the server just sent the data in a normal packet
immediately after the SYN/ACK?

The resulting sequence would be:

  Client     Server
   ------SYN---->
   <---SYN/ACK---
   <====Data=====
   ------ACK---->

I think that this would be compliant to RFC 793. I would also expect
that many clients would accept this data packet if it arrives after
the SYN/ACK, i. e., if there is no reordering. This could also save
one RTT of latency, and the overhead of one packet would not be that
large.

Do I miss something?

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

[Adam Langley-2]

On Tue, Jul 15, 2008 at 11:53 PM, Michael Scharf
<michael.scharf@...> wrote:
> sorry for asking once again "stupid" questions: Wouldn't it be a
> simple solution if the server just sent the data in a normal packet
> immediately after the SYN/ACK?

That's a very interesting idea; I hadn't considered it.

The pros would be that one could imagine that the active open host
wouldn't need any changes to support it. Let's consider what could go
wrong:

Packet loss: shouldn't be an issue. If the SYNACK is lost, the packet
with a payload would, at worst, get ignored. Possibly some stacks
would enqueue it.
Reordering: again, should be fine. Since the data packet is affecting
the sequence numbers it would get retransmitted if it was dropped
because it arrived early.

However, application level protocols probably need to change in order
to take advantage of early passive-open data transmission. Either
because they weren't designed with that in mind or because they need
to be a lot more frugal with their bits to fit within the 64-byte
limit. So the option in the SYN would still be needed, and that means
there's an issue of consistency. Both sides need to know if early-data
is in play because it affects the application level. Consider

AO: active open host
PO: passive open host

1. AO: A SYN is sent with SYNPACK Payload Permitted
2. PO: A SYNACK reply is sent and a data packet is sent
3. AO: A timeout occurs and the SYN is retransmitted without the
permitted bit. Although I don't think middleware dropping the unknown
option is going to be too much of a problem (see citations in the
draft), it's good if hosts have the option of doing this
4. AO: The SYNACK packet (from step 2) arrives. ACK is sent
5. AO: The data packet (from step 2) arrives and is enqueued.
5. PO: The second SYN causes another SYNACK (which will be ignored by AO)
6: PO: The ACK arrives

Now, neither side believe that an extra data packet was in play (AO
because it timed out and transmitted without the permitted bit in 3
and PO because it got a SYN without the bit in 5). However, the data
reaches the application level.

This means that we have to mark the data packet in some way (probably
an option) so that AO can drop it at step 5. Alternatively we could
require that, if the AO host wishes to back off from sending the
permitted bit, it has to start a whole new connection.

Another con would be the, minor, additional SYN flood problems - a SYN
can now elicit two packets and an additional 30 (or so) bytes from a
host.

So I think the balance comes out against, but it was very much worth
the consideration.

Thanks

AGL


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