Re: [tcpm] Faster application handshakes with SYN/ACK payloads

["Adam Langley" <[e-mail]>]

On Sun, Aug 3, 2008 at 9:56 PM, Anantha Ramaiah (ananth)
<[e-mail]> wrote:
> - fix the sentence : "we should how this has...."

Thanks! will do.

> - you mention "cryptographic applications" would benefit with this
> proposal, and give example of SSH in your draft. It would be really
> interesting to know how many very commonly used TCP applications would
> really benefit with this ? Atleast the draft can mention those..

Will do with the next draft.

> - with the SSH example which you give, it appears that one of the
> advantages of this proposal is that you can tear down the connection
> before the connection moves to ESTAB if the authentication fails?  (For
> eg:- some implementations don't create a full blown TCB before TWHS
> completes)

Indeed. Although I believe that a (short lived) TCB would actually be
created in this case for current, common stacks, that's an
implementation limit. It would be possible, with the authentication
that I sketched, for neither end to create a TCB if the server's
public value didn't match.

> - Can you elaborate on the flags option? It simply mentions that the
> meaning of this would be assigned by IANA? Again this is not infinite
> (2+n, n is finite) since it should be bounded by the TCP header length
> inclusive of options?

The flags option was designed to allow future flag options to be
assigned bits, rather than option numbers. Consider that, if SACK
permitted has been designed this way, then this proposed option
wouldn't need any extra options space, it could just take a bit in an
option that it already ubiquitous. However, it might well be the case
that I should just stick to a standard, 2 byte, option for this.

> - the doc says (section 3 ) "host MUST not include data payload in
> SYN+ACK resulting from a SYN frame without SYNACK payload permitted"
> But RFC 793 does permit data in SYN which includes SYN+ACK, so this
> statement raises a new level of ambiguity.

Thanks. Joe pointed out this ambiguity also. It will be fixed in the
next draft by echoing the option in the SYNACK.

> Section 4:
>
> You mention 64 bytes of payload is enough to include sufficient crypto
> material. Just wondering the interoperability of this statement with TCP
> auth (TCP MD5 and TCP AO for example)

The method for upgrading a normal connection to TCP AO is currently
not specified, although there has been discussion of it. In my
current, very rough, patches there's an option that I'm calling LATCH
that allows a connection to upgrade to TCP AO. Also, I have userspace
software that uses SYNACK payloads and LATCH to establish a connection
and upgrade to TCP AO using the agreed key (and no additional round
trips). Fundamentally, however, these drafts are independent.

> What about Kamikaze like packets ? where SYN, FIN are set the
> applications can send data and also set the FIN bit in the oriinal SYN
> (Not sure if 793 talks about it but Stevens book does mention it and so
> as BSD implementatiosns which support this type of packets) Would those
> still work within your proposal?

I would have to investigate how the BSD stacks handle this. Linux
would ack only the SYN flag, to the other host would have to
retransmit any data and the FIN anyway. BSD stacks, I hope, would not
deliver data to userspace with an unauthenticated source IP address,
so may do the same. But it isn't incompatible with my scheme. The
SYNACK payload, if configured, would be sent as part of the data
stream.

> Also, the applications need to change to make use of this proposal (the
> HTTP example which you mention below) In other words, it would be nice
> if you can explain the "opportunistic encryption" scheme and how
> applications (which all) can benefit from your proposal in more detail
> in the draft.

Since several people have suggested this, I certain shall in the next
draft (which should be in the next couple of days)

Thanks for your comments.


AGL

-- 
Adam Langley [e-mail] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm