David, > > My view is that this document has to change significantly before we > > can discuss adoption. Since this proposal significantly modifies the > > TCP protocol and the TCP state engine, I'd really prefer to *first* > > have a consistent document and *then* discuss a potential adoption. > If > > the consensus in TCPINC is not to use header protection, I think > > header protection has to be removed entirely from the protocol > > specification - it could go to a separate document. > > Hi, Michael. I'd like to address some of your points, and attempt to > provide and request clarification on others. So long as tcpcrypt is a > viable contender, we will of course produce an updated draft to disable > default header protection.
I digreee that disabling is the right approach. My suggestion is to entirely remove all discussion of header protection from draft-bittau-tcpinc-tcpcrypt, so that it is clear how a TCPINC protocol looks like without header protection (if draft-bittau-tcpinc-tcpcrypt was used as a base protocol for TCPINC). Header protection can go do a separate document. > > I've stated already multiple times that I am really concerned about > > the definition of an own option payload encoding for INIT1 and INIT2 > > [1]. TCPM has a chartered milestone for EDO to provide long > > options. To me, EDO provides what is needed for INIT1/INIT2. If I > miss > > something here, I am really willing to learn more. I do not think > that > > the TCPINC working group should define a second and incompatible TCP > > long option format. This will very likely result in incompatibility > > issues once EDO, TCPINC, and/or other TCP extensions evolve in the > > future, or if they will be used in combination. The last thing we > need > > in the IETF is standardizing multiple incompatible TCP variants each > > defining their own encoding of the data stream. This will end up in a > > mess. I believe updating draft-bittau-tcpinc-tcpcrypt to use EDO > would > > only be a small change of the protocol. > > It seems that you are asking us to move the body of the INIT1 and INIT2 > messages into option space using EDO. But TCP-use-TLS does not put the > key exchange into option space, either. So on this point are you > equally opposed to the TCP-use-TLS proposal? No, I just strongly oppose to an adoption of draft-bittau-tcpinc-tcpcrypt in its current form. As far as I understand, TCP-use-TLS has its own framing in the TCP payload, and it is thus inherently robust to all middleboxes messing up TCP options. This seems a clean approach and looks future-proof to me. Regarding interaction with other TCP features, there is no reason to oppose to the TCP-use-TLS approach. However, I do not understand why TCPINC should need a TCP option outside the SYN. This would probably needed for header protection only. To me, payload protection does not need TCP options after initial negotiation. I do not care whether the actual protocol running in the TCP payload is TLS, or whether it is a protocol using the crypto principles of tcpcrypt, or whether it is some third protocol still-to-be designed. This has to be sorted out by the crypto experts. I can even imagine that the IETF specifies several different TCPINC protocols in the TCP payload. >From a TCP perspective, all these designs running in the TCP payload are >equal. Once the upgrade to encryption is negotiated in the SYN, the TCP >protocol engine (including segmentation offloading etc.) does not have to care >about the crypto features. > INIT1 and INIT2 are part > of the session. For example, it could be necessary for INIT1 to exceed > the size of a single TCP segment. Why re-invent TCP to stitch together > options over various segments when TCP already has a nice mechanism for > reliable in-order data delivery? Indeed, use of options for something that can be done in the payload is not the right approach. TCP is pretty efficient in doing reliable in order delivery. My suggestion is just leverage that TCP transport for all control information needed by TCPINC. Just put INIT1/INIT2, the MACs, etc. in the payload and use a clear framing method to distinguish the messages (typically this would be TLV). KISS design principle. Unless there are excellent reasons not to go down that road, which I do not see so far. > > If EDO as currently defined was not sufficient for TCPINC, the TCPM > > working group would be really open to feedback [2]. Supporting > > combinations of TCP-AO, MPTCP, TCPINC, etc. was the main reason why > > TCPM decided to start the design of a long option solution. > > Speaking as a tcpcrypt author, I strongly support the adoption of an > EDO > option, and believe tcpcrypt would benefit through more graceful > coexistence with other options (particularly large SACK blocks). If you decide not to change to TLV, you should at least use EDO in the next version of draft-bittau-tcpinc-tcpcrypt. I actually believe that when entirely removing the header protection from draft-bittau-tcpinc-tcpcrypt, a lot of the protocol features of tcpcrypt can significantly be simplified, which results in a better and more robust protocol design. But since this is speculation only at this stage, my key message is that I'd first like to have a look how the protocol specification without header protection and without a proprietary option encoding format looks like, before discussion any WG adoption. > > I also expect that a TCPINC protocol will (hopefully) evolve in > > future, and the TCPINC community should therefore develop a > > future-proof design. I imagine that future TCPINC enhancements could > > need the exchange of additional data, possibly exceeding the 40B > > option limit like INIT1/INIT2. In this case, a TCPINC protocol using > > the current tcpcrypt payload encoding could easily require further, > > very complex long option encoding hacks to be able to transport the > > data needed by such TCPINC extensions. As a result, I believe that > the > > current INIT1/INIT2 encoding is not future-proof and may prevent an > > evolution of the TCPINC protocol itself. Again, if I should miss > > something here, I am willing to learn more. > > Can you give an example of why you think this is not future proof? Our > INIT messages have a 4-byte magic number and 4-byte length. I can't > see > any scenario in which we would need more than 4GiB of key exchange > data, > but if the need really does arise we can just specify new magic numbers > with an 8-byte length field. My point is not the INIT1/INIT2 encoding. My concern is that somebody will in future come up with a new feature of TCPINC, e.g. a better way to protect against certain new attacks currently not known. Imagine that this extension will need more than 40B of control data. This will in particular be challenging if that information should be required mid-stream, in combination with resegmenting middleboxex etc. In that case, without either using EDO or a clean payload framing like TLV, the TCPINC community may easily have to use very complex tricks to reliably exchange said control information. Basically, TCPINC will have to solve all problems again that TCPM discusses for EDO right now. I consider it rather likely that extensions of TCPINC will be suggested in the years to come - there is usually lots of innovation in transport protocol design. I think TCPINC should define a base protocol that allows such extensions. In particular if the ambition is to become the default transport in the Internet. So, either use EDO or just pick a payload encoding such as TLV that does not have all those problems. The latter would be strongly preferred. > > I am not a crypto algorithm expert. But without the need to offer TCP > > header protection, I assume that the unauthenticated encryption > > features of tcpcrypt can also be provided by a TLV encoding (or > > something equivalent) inside the TCP data stream. I'd assume that the > > actual protocol inside the TCP byte stream could be different to TLS > > if diversity was an important design objective - this part of the > > design has to be sorted out by security experts. In addition to a > much > > cleaner protocol architecture not interfering with other TCP > > extensions, such a TCPINC design would also waste less scarce TCP > > option space and seems clearly superior to the current design in > > draft-bittau-tcpinc-tcpcrypt. > > So the way I see the two options we were asked to chose between, > TCP-use-TLS uses TLV for both key exchange and data, while tcpcrypt > uses > TLV for key exchange only (namely INIT1 and INIT2). I think Joe Touch > would prefer TLV for neither. You now seem to be advocating a fourth > design point which uses TLV for data only. Maybe I misunderstand you, > since we've had a number of drafts and no one has yet advocated that > design point. I advocate not to mix payload and option encoding. This is a hack. Either use EDO and put everything into options, or use TLV in the payload for everything. The latter approach is much simpler and has much less interoperability issues with other TCP extensions. Therefore, I think TCPINC would need strong arguments not to TLV. But this is up to the community to decide. Maybe this community should try to summarize if there are any reasons not to use TLV. > I think TLV has disadvantages for data. For example, it may increase > latency if authentication doesn't fall on segment boundaries. But That additional latency is the time between two consecutive segments, right? On a 100 Mbps link with 1500 byte MTU, this corresponds to 0.1ms. Is this really a significant effect? Also, a sender can try to avoid this additional latency by an intelligent segmentation strategy. I'd actually assume that segmentation offloading is much more relevant for throughput and latency. I assume segmentation offloading inherently works for any TLV design (including TLS). Has tcpcrypt been tested with hardware segmentation offloading? > non-TLV also has disadvantages, such as consuming options space that > could otherwise be used for larger SACK blocks (though EDO could really > help here). This is something I would expect the working group to > debate. But I don't see any disadvantage to TLV for key exchange. > (Possibly you could argue it undermines the "TCPness" of the protocol, > but not if you are anyway using TLV for session data.) I really think the TCPINC working group should debate whether there is *any* reason not to use TLV in the TCP payload, given that header protection is out of scope. This question seems entirely independent of the question whether the protocol using the TLV data structure is TLS or something else. Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
