On 7/30/2016 4:26 PM, David Mazieres expires 2016-10-28 PDT wrote: > Joe Touch <[email protected]> writes: > >>> On Jul 30, 2016, at 10:20 AM, David Mazieres >>> <[email protected]> wrote: >>> >>> And mandating no >>> buffering of discarded SYN data is a good way to do that... >> You can do that for ENO, but you cannot assert requirements for legacy >> stacks. >> >> The problem is that you keep saying you "know" when the other end >> supports ENO based on previous state, but if that were really true you >> wouldn't need to negotiate ENO in the 3WHS. > No, I'm saying *if* the application knows the other end of a connection > supports ENO, It doesn't until the SYN-ACK.
Let me put it this way - if you know the other end supports ENO, then you clearly don't need to negotiate it in the SYN. Is that what you do? > and in particular *if* the application intends to abort an > unencrypted connection anyway, TCP needs to be the one making that decision, because an "app" that doesn't make that decision could be experiencing TCP semantics that are incorrect. > *then* it probably makes sense for the > application to send data in a SYN segment. An app doesn't make that decision - it can do things to prevent it from happening (i.e., waiting for the connection to be open before writing data), but it can't force this behavior. It's not in the user interface defined in RFC793, so you can't assume it (unless you're creating this definition solely for ENO, which seems far out of scope to me). > You are right that if we could have an internet flag day, we wouldn't > need TCP-ENO at all. But getting from the status quo to our goal of > ~100% encrypted TCP traffic requires multiple stages--first > opportunistic encryption, then shimming in some sort of endpoint > authentication, finally having applications or middleware drop > unauthenticated connections. That's one possible future. Another is one where TCPINC dies off and is replaced by something else, either at the TCP layer or IP. > If TCPINC succeeds, people may, for > example, configure NFS servers not to talk to workstations over > unencrypted TCP. By that point it makes to discuss TEPs supporting SYN > data, but not now. Now the question before the working group is how ENO > should avoid preempting/complicating those future discussions. It also needs to avoid adverse interactions with not using ENO at all. > So far I haven't heard any objections to anything before the last > paragraph of section 4.7, which means the discussion needs to focus on > that last paragraph, namely: First, just because I say the food is salty, doesn't mean it's great if you fix the salt level. But yes, this part needs fixing. > Using data in SYN segments deviates from TCP semantics and can cause > problems with middleboxes or non-compliant TCP hosts. Hence, all > TEPs SHOULD support a normal mode of operation that does not make use > of data in SYN segments. Moreover, implementations SHOULD employ SYN > data only if explicitly requested by the application or in cases > where such use is highly unlikely to pose problems. > > I think you've objected to the word "using" as too vague, and maybe Yes.. > would prefer "standard TCP semantics" to make clear we aren't talking > about TFO. Yes. Then there's the part about middleboxes (it's useless to make "laws for the lawless", i.e., if your goal is to modify TCP in ways that are compliant with all middleboxes, you can stop now). Then there's the part about non-compliant hosts - actually, "using" data in the SYN violates the semantics of TCP for *compliant* hosts. > You did not answer my question about whether the word > "consuming" is better than "using". It's needlessly anthropomorphic. The answer is simple - if the receiver (ENO or otherwise) uses the information in the SYN data (i.e., it changes its behavior in any way based on that content), then it MUST happen after TFO only (at this point) or a true equivalent. There is *no* aspect of ENO that currently supports that level of equivalence - i.e., *validated* by a SYN cookie. You don't get to make that assumption based on any "belief" of the other end's state > You also did not answer my question > about whether you would support a sentence saying active openers SHOULD > abort non-ENO connections if they have sent SYN data (though at this > point I think such a sentence would be good). MUST, and it MUST occur inside TCP. You can't assume that happens at the application (user) layer. Note that I already said this when I gave you two choices: a) never send anything you can't retract in the SYN-ACK or b) always abort - inside TCP - a connection where you would have needed to do that retraction > Your arguments seem > primarily directed at some hypothetical future straw-man TEP sending > encrypted SYN data to non-ENO aware hosts, but no existing TEP proposal > does that and more importantly that is not the question at hand. You seem to be operating under the mistaken belief that sending data to the same IP address twice always reaches the same TCP context. I.e., when you send TCP-encrypted SYN data to a host, you have NO WAY OF KNOWING whether that host is ENO-capable until AFTER the SYN-ACK. Otherwise, if you did COULD already know that, you clearly wouldn't need the ENO flag at all. Since you need that flag, then you need to consider the case where it is wrong. > So on the topic of TCP-ENO, do you have specific suggestions for > improving the last paragraph of section 4.7 of the draft? > > See above. Note that this does not imply that I consider the entire draft otherwise correct. Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
