Re: [tcpm] SYN/ACK Payloads, draft 01

Hi Adam.
Again, inline :)
Regards,
Sergio Freire

-----Original Message-----
From: alangley@gmail.com [mailto:alangley@gmail.com] On Behalf Of Adam Langley
Sent: terça-feira, 12 de Agosto de 2008 19:55
To: Sergio Freire
Cc: andre.zuquete@ua.pt; tcpm@ietf.org
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01

On Tue, Aug 12, 2008 at 10:17 AM, Sergio Freire <etfreire@ua.pt> wrote:
> Sergio: I think it would be great to handle also additional payload. If we are changing things at this level I think it would be of great valor to handle the two cases :) I still have to look carefully at your draft.

Sadly, I don't believe that there is a good way to include extra
options space in a SYN frame in a backwards compatible manner. You're
trick of using port 0 is one such way, but obviously ties it to an
alternative port resolution scheme.

Sergio: well, we must figure out the best way to achieve this. Using a destination port 0 was a solution we devised in our specific case. Again, we want to generalize this and consider other possibilities like the one depicted on my next comment.

> However, if you aren't setting dport to 0 to signal that the SYN is
> special, then hosts may interpret the payload of the SYN frame to be
> application level data. Joe's portname draft uses options to avoid
> this.
>
> Sergio: Actually they don't, because in that specific case the destination host would have to understand port names.

I'm suggesting that if you sent a SYN with a payload and a random
destination port to a host, that host, if the port was open, could
interpret the payload to be application level data and reply with a
SYNACK. Although you would notice that it wouldn't echo your option.

Sergio: Yeap! That is an option we are considering: resetting the connection if the SYNACK does not contain the given TCP option.

> Sergio: Right, in my thesis that was corrected. Thanks. Let me explain how segments are
> correlated: src_IP+src_port+dst_IP+dst_port. Since the destination port in SYN may be 0
> and the source port in SYNACK is always the resolved port. So, there must be another field
> to correlate, which in this case we decided to use the portname.

I understand that you've lost one of the elements of the 4-tuple that
identify a connection, I was suggesting that you could just do without
it if your source ports for conections were random. There might be a
case in which this goes wrong that I'm not thinking of right now. I
guess it is rather against the TCP spirit. Fundamentally, I don't
believe that this conflicts with my SYNACK payloads draft. The option
in the SYNACK can easilly denote the portname from the application
level data.

Sergio: yes, by maintaining the connection elements (the 4-tuple) during connection solves many problems. Yet, there's a possibility of connecting to wrong services (e.g. imagine a server that is bound to some X port... the client issues a connection and the randomly chosen destination port at client side is X... this will collide with an existing service). But again, this can be "solved" looking at the SYNACK reply, for example.
About your draft, let me take a look first.

Also, SYN crossings are interesting with this scheme. I think they
work, but it's complicated. The ACKs, in this case, would also have to
include the portname. I think a SYN crossing where one of the sides
isn't using the portname to resolve the other goes wrong though.

Sergio: Nice that you thought about this. In fact, we didn't considered simultaneous connections mainly because nobody seems to be using them. 
Besides that, the paradigm is like a client/server model: the client tries to connect to a server which is bound to a name.
The client itself does not have a name. So, it does not make too much sense to think on this case using this paradigm, unless the connection comes from the socket server but that does not make sense.
If the client and the server both have names, then SYN crossing would make sense.

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org

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