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

Inline..

-----Original Message-----
From: alangley@gmail.com [mailto:alangley@gmail.com] On Behalf Of Adam Langley
Sent: terça-feira, 12 de Agosto de 2008 17:14
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 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 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.

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

Sergio: well, using Joe Touch's portname draft, which is a bit different from our approach, you could. Anyway, you can also think on specifying the destination port number (your default portnumber) instead of 0. In that case we would need to signal the portname and maintain the legacy compatibility using another method.

> 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: Actually they don't, because in that specific case the destination host would have to understand port names.

> 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

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.

AGL

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

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