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.

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

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.

AGL

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