Bryan Ford <[email protected]> writes:
> - Section 2, Introduction: insert “, if needed by the negotiated
> protocol,” somewhere appropriate in bullet 6 at the very end of this
> section.
That bullet says, "so as to name each end of a connection for encryption
or authentication purposes." So what if it's needed for authentication?
> * If both endpoints play the active role, e.g., in the case of
> TCP simultaneous-open, then each endpoint will first send a SYN
> packet (without the ACK flag set) containing ENO options; then
> upon receiving the other endpoint’s SYN packet, each endpoint
> will send an ACK packet containing an empty ENO option in order
> to confirm receipt of the other endpoint’s ENO options.
The reason I'm asking you for tcpdump output or at least an "A->B"-style
packet flow diagram is that this isn't how simultaneous open works, yet
it's easy to convince yourself that stuff like this works when you don't
go through the trouble of creating and staring at a packet flow diagram.
TCP-SO requires two SYNs followed by two SYN-ACKs. Any realistic
scenario involves a stateful firewall or NAT dropping one of the two SYN
segments; otherwise, whoever connected first will get an RST segment and
abort the connection. Hence, the SYN-ACK must contain the same ENO
option as the SYN. Moreover, an overwhelming faction of the time
exactly one end of the TCP connection will know that this is a
simultaneous open, while a small fraction of the time you will get
"lucky" and both ends will receive SYNs without ACK.
Consider how weird it is that we've wasted so much time emailing about
TCP-SO when we don't even share a basic understanding of how the
mechanism works. I conjecture this is because TCP-SO essentially
doesn't exist in the wild. Since we can't observe it, we make up
strange theories about how it works or how it might be useful. With no
empirical basis, these theories do not provide useful guidance for the
design of TCP-ENO.
> - The “negotiated spec” paragraph needs to be adjusted as I proposed
> in my earlier E-mail: e.g., from each list of supported specs, take
> the last spec from each list that is present in both lists, and if
> they are different, just choose (say) the numerically higher one,
> instead of choosing the one proposed by host B.
I think it's a little weird to favor higher code points. It effectively
makes RAW mode an impractical implementation technique for servers with
well-defined spec preferences. But while I'm adamant about not
complicating the API, if you solve the API problem, RAW mode is
something I would at least consider changing or getting rid of.
> - Just delete the paragraph that start “When possible, host B SHOULD
> send only one spec identifier…”
Why? First it's a SHOULD, not a MUST. Second, it seems even more
important now that code points reflect some kind of weird priority that
almost certainly doesn't capture anyone's preferences. Finally, there's
plenty of precedent for even stronger restrictions dating back at least
to RFC1323 ("Furthermore, an extension option will be sent in a
<SYN,ACK> segment only if the corresponding option was received in the
initial <SYN> segment.") I'm not saying I agree with RFC1323, just that
TCP's supposedly symmetric design hasn't really been symmetric since the
early 1990s.
Okay, I'm not even going to address two transcripts issue, because A) if
you solve the API problem the solution to the transcript will follow
naturally, and B) I think this whole thread is a giant waste of time
until we have a concrete example of TCP-SO use that could benefit from
TCPINC.
Also, to reemphasize the API point, if there's any application using
TCP-SO that could benefit from TCPINC, it's probably a peer-to-peer
application. And that style of symmetric application is precisely the
kind most likely to be tricked into thinking it has connected to itself.
So roles are especially important in peer-to-peer applications. (In
other settings, the application will know if it was an active or passive
opener, but the API ROLE calls are still necessary so that people can
implement "idiot-proof" authentication libraries that don't rely on
getting this information properly from the application.)
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
