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

On Tue, Aug 12, 2008 at 6:44 AM, Sergio Freire <etfreire@ua.pt> wrote:
> What we intend to do is to split this two concepts and propose:
>  a) a way to extend the space available for TCP options, by reusing the payload of TCP segments
>  b) a generalization of the TCP-layer name service using the functionality provided by a)

For a) also see [1], although it doesn't do anything for including
extra data in the SYN frame.

> Sergio: I'm not sure if I've understood correctly but I think so. In our model you can establish a connection to a named service. The connection can be either established from a legacy client or from an "enhanced" portname aware client. If the connection is established from a legacy client, then it must be established to the fixed port number where the service was bound (and not 0). If the client is portname aware, then it can either establish a connection to destination port number 0 (and the given portname) or to the specific destination port number (if the service was bound to a specific port number).

Right, it's just unfortunate that a client connecting to a portname
cannot fallback to a default portnumber. (For example, connecting to
"http", but also setting the destination port to 80 for server which
don't understand that). However, I don't believe that there's any way
to do that.

> Actually changing ports during a connection raises some problems like in firewalls, NAT boxes.

Indeed, NATs strike again. I believe most of them would fail in this situation.

> We have to chose another approach like Joe Touch's suggestion of a randomly chosen destination port number at client side (see portnames draft from J.Touch).

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: No. There is payload in the SYNACK, which corresponds to the same payload we used in the SYN. We use it to correlate both packets. There was a typo bug in the initial paper in that table though. I think it's correct as it is now.

In the bottom right cell of the table, the final ACK is only acking
ISN_s + 1, should it not be ISN_s + 1 + L? (Unless the echoed data in
the SYNACK isn't acked). Also, I don't understand why you need this to
correlate the packet - you have the destination port in the SYNACK.

[1] http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-01.txt

AGL

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